Booth package-wise modularizing (discussion)

[jnpkrn]

Hello @dmuhamedagic at al.,

it occurs to me that it's an overhead to have booth package serve
all possible roles incl. arbitrator.

I envision that arbitrator specifically could be split to a package
on it's own (booth-arbitrator containing the initscript/systemd units
and its config file).

However, as it uses the same binary as a proper booth package, more
packaging surgery would be needed. So one of the possible lines of
splitting could be that the OCF agent stuff is in a dedicated
booth-agent package.

Plain booth would remain the core carrying the binary,
booth-keygen, doc and license files etc., and would be required
by both booth-arbitrator and booth-agent.

It's a half-baked idea, only to see if it's viable.
If positive, also a safe mechanism for upgrade/downgrade path would
have to be ensured (via Obsoletes, etc.).

Suggestions/objections?

[jnpkrn]

Actually, booth-site seems a better choice over booth-agent.

[dmuhamedagic]

There are only two roles, site and arbitrator. As you noted, both are provided by a single binary. Not only that, but also booth client is implemented within the same binary. I guess that it would be possible to split it into several packages. However, I'm not sure what would be the benefit to justify the effort.

[jnpkrn]

On 07/04/16 03:36 -0700, Dejan Muhamedagic wrote:

There are only two roles, site and arbitrator. As you noted, both
are provided by a single binary. Not only that, but also booth
client is implemented within the same binary.

I guess that it would be possible to split it into several
packages. However, I'm not sure what would be the benefit to
justify the effort.

Primary intention:
Make misconfiguration harder for happy-path admins that read
documentation only if something explodes.

By-product advantages:

• make booth-site properly depend on resource-agents for
  • %dir /usr/lib/ocf
  • %dir /usr/lib/ocf/resource.d
  • /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs (and perhaps more)
    (neither resource-agents nor pacemaker are really needed for
    the arbitrator role, right?)

Actually my current line of thinking, in Fedora context, is to
have the "common" parts in booth-common, make booth package empty
and have "Provides: booth" at booth-site.

This way, installing booth (as well as booth-site that will actually
make it to dnf search results) will pull-in everything needed for
site role and for arbitrator, one would install booth-arbitrator
explicitly.

For non-Fedora, it could be the same, plus either booth-site or
booth-common (transitive dependency of the former) requiring
booth-arbitrator, and everything works as before. Or some
other schema.

Of course, Fedora packaging can diverge from upstream, but at
least partial consistency bears more benefit in long term, IMHO.

Jan (Poki)

[jnpkrn]

On 07/04/16 16:09 +0200, Jan Pokorný wrote:

By-product advantages:

• make booth-site properly depend on resource-agents for
  • %dir /usr/lib/ocf
  • %dir /usr/lib/ocf/resource.d
  • /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs (and perhaps more)
    (neither resource-agents nor pacemaker are really needed for
    the arbitrator role, right?)

...leading to another one:

• booth-arbitrator doesn't need to pull in pacemaker, effectively
  preventing significant creep of unwarranted dependencies

This seems to be a big win, actually.

Jan (Poki)

[dmuhamedagic]

On Thu, Apr 07, 2016 at 07:09:17AM -0700, Jan Pokorný wrote:

On 07/04/16 03:36 -0700, Dejan Muhamedagic wrote:

There are only two roles, site and arbitrator. As you noted, both
are provided by a single binary. Not only that, but also booth
client is implemented within the same binary.

I guess that it would be possible to split it into several
packages. However, I'm not sure what would be the benefit to
justify the effort.

Primary intention:
Make misconfiguration harder for happy-path admins that read
documentation only if something explodes.

Heh, such admins should stay away from HA. If we're on to
reckless maintenance, then better not start with clustering at
all, let alone booth.

By-product advantages:

• make booth-site properly depend on resource-agents for
  • %dir /usr/lib/ocf
  • %dir /usr/lib/ocf/resource.d
  • /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs (and perhaps more)
    (neither resource-agents nor pacemaker are really needed for
    the arbitrator role, right?)

Right. Though introducing resource-agents may lead to circular
dependency.

Actually my current line of thinking, in Fedora context, is to
have the "common" parts in booth-common, make booth package empty
and have "Provides: booth" at booth-site.

This way, installing booth (as well as booth-site that will actually
make it to dnf search results) will pull-in everything needed for
site role and for arbitrator, one would install booth-arbitrator
explicitly.

For non-Fedora, it could be the same, plus either booth-site or
booth-common (transitive dependency of the former) requiring
booth-arbitrator, and everything works as before. Or some
other schema.

Of course, Fedora packaging can diverge from upstream, but at
least partial consistency bears more benefit in long term, IMHO.

Definitely. I'm also all for improvement.

...leading to another one:

• booth-arbitrator doesn't need to pull in pacemaker, effectively
  preventing significant creep of unwarranted dependencies

This seems to be a big win, actually.

Unfortunately, this won't be that trivial, the arbitrator
implementation being in the same binary which depends on
pacemaker. I'm not sure if it links against some pacemaker
libraries too? But, essentially, yes, I agree that the arbitrator
shouldn't need pacemaker.

[jnpkrn]

On 12/04/16 09:04 -0700, Dejan Muhamedagic wrote:

On Thu, Apr 07, 2016 at 07:09:17AM -0700, Jan Pokorný wrote:

By-product advantages:

• make booth-site properly depend on resource-agents for
  • %dir /usr/lib/ocf
  • %dir /usr/lib/ocf/resource.d
  • /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs (and perhaps more)
    (neither resource-agents nor pacemaker are really needed for
    the arbitrator role, right?)

Right. Though introducing resource-agents may lead to circular
dependency.

Can you be more specific about such a cycle please?
I can only imagine a very hilarious case of resource-agents or
any of its dependants to rely on booth.

Actually my current line of thinking, in Fedora context, is to
have the "common" parts in booth-common, make booth package empty
and have "Provides: booth" at booth-site.

This way, installing booth (as well as booth-site that will actually
make it to dnf search results) will pull-in everything needed for
site role and for arbitrator, one would install booth-arbitrator
explicitly.

For non-Fedora, it could be the same, plus either booth-site or
booth-common (transitive dependency of the former) requiring
booth-arbitrator, and everything works as before. Or some
other schema.

Of course, Fedora packaging can diverge from upstream, but at
least partial consistency bears more benefit in long term, IMHO.

Definitely. I'm also all for improvement.

...leading to another one:

• booth-arbitrator doesn't need to pull in pacemaker, effectively
  preventing significant creep of unwarranted dependencies

This seems to be a big win, actually.

Unfortunately, this won't be that trivial, the arbitrator
implementation being in the same binary which depends on
pacemaker. I'm not sure if it links against some pacemaker
libraries too?

The dependency is on pacemaker-cli for run-time (not runtime of the
arbitrator role, though, and on a few return code related constants
defined in pacemaker/crm/services.h (from pacemaker-libs-devel)
in build-time (no linking).

But, essentially, yes, I agree that the arbitrator
shouldn't need pacemaker.

This is what the new packaging order would achieve.

My version in the works now uses -core package to carry
the binary + booth symlink, config example, README, license
etc. and both -arbitrator and -site requiring it.

Jan (Poki)

[dmuhamedagic]

On Tue, Apr 12, 2016 at 01:32:25PM -0700, Jan Pokorný wrote:

On 12/04/16 09:04 -0700, Dejan Muhamedagic wrote:

On Thu, Apr 07, 2016 at 07:09:17AM -0700, Jan Pokorný wrote:

By-product advantages:

• make booth-site properly depend on resource-agents for
  • %dir /usr/lib/ocf
  • %dir /usr/lib/ocf/resource.d
  • /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs (and perhaps more)
    (neither resource-agents nor pacemaker are really needed for
    the arbitrator role, right?)

Right. Though introducing resource-agents may lead to circular
dependency.

Can you be more specific about such a cycle please?

Nevermind, the direction I had in mind was wrong.

I can only imagine a very hilarious case of resource-agents or
any of its dependants to rely on booth.

Actually my current line of thinking, in Fedora context, is to
have the "common" parts in booth-common, make booth package empty
and have "Provides: booth" at booth-site.

This way, installing booth (as well as booth-site that will actually
make it to dnf search results) will pull-in everything needed for
site role and for arbitrator, one would install booth-arbitrator
explicitly.

For non-Fedora, it could be the same, plus either booth-site or
booth-common (transitive dependency of the former) requiring
booth-arbitrator, and everything works as before. Or some
other schema.

Of course, Fedora packaging can diverge from upstream, but at
least partial consistency bears more benefit in long term, IMHO.

Definitely. I'm also all for improvement.

...leading to another one:

• booth-arbitrator doesn't need to pull in pacemaker, effectively
  preventing significant creep of unwarranted dependencies

This seems to be a big win, actually.

Unfortunately, this won't be that trivial, the arbitrator
implementation being in the same binary which depends on
pacemaker. I'm not sure if it links against some pacemaker
libraries too?

The dependency is on pacemaker-cli for run-time (not runtime of the
arbitrator role, though, and on a few return code related constants
defined in pacemaker/crm/services.h (from pacemaker-libs-devel)
in build-time (no linking).

Yeah, we need to make sure that booth never tries to invoke
pacemaker-cli binaries when running as an arbitrator.

But, essentially, yes, I agree that the arbitrator
shouldn't need pacemaker.

This is what the new packaging order would achieve.

My version in the works now uses -core package to carry
the binary + booth symlink, config example, README, license
etc. and both -arbitrator and -site requiring it.

But one thing I'm missing: if booth-core depends on pacemaker-cli
and booth-arbitrator on booth-core, how do you avoid installing
pacemaker?

[jnpkrn]

On 18/04/16 07:43 -0700, Dejan Muhamedagic wrote:

On Tue, Apr 12, 2016 at 01:32:25PM -0700, Jan Pokorný wrote:

On 12/04/16 09:04 -0700, Dejan Muhamedagic wrote:

But, essentially, yes, I agree that the arbitrator
shouldn't need pacemaker.

This is what the new packaging order would achieve.

My version in the works now uses -core package to carry
the binary + booth symlink, config example, README, license
etc. and both -arbitrator and -site requiring it.

But one thing I'm missing: if booth-core depends on pacemaker-cli
and booth-arbitrator on booth-core, how do you avoid installing
pacemaker?

The imposed loop breaking is why I deliberately made booth-core
a free-floating package (only Requires: coreutils, for chown+dd in
booth-keygen), meaning that you'll get something possibly usable
as a client at best -- asking for more naturally implies asking for
booth-arbitrator or booth-site packages (booth-test require both).

(Rhyme time: if you are to install just booth-core,
you're pretty much expected to be hardcore.)

And just booth could then be an empty envelop package/Provides
pulling in what's considered "booth" installation in the particular
distro (likely a proper superset of booth-core).

Jan (Poki)

[jnpkrn]

For how I eventually split booth into Fedora packages, see:
https://pkgs.fedoraproject.org/cgit/rpms/booth.git/tree/booth.spec#n1

What might be doable to ensure full compatibility with old-style
monolithic packaging (understandable requirement for smooth experience
within the major distro release) is let booth envelope require also
booth-arbitrator the same way booth-site is required.
Or perhaps there's a way to retain arbitrator-related files
just on upgrade even without that (would have to play with that
more extensively to find the answer).

Note also the Conflicts tags. If upstream spec is to adapt the
proposed split scheme, it would be best if it was done amongst the
last pre-release commits (if not the very last one) while setting
that value to %{name} < VERSION-TO-BE-RELEASED-1, where
VERSION-TO-BE-RELEASED can be something as 1.1 or 1.0.1
(have you figured out the subsequent versioning, yet?).

[dmuhamedagic]

On Fri, May 06, 2016 at 11:57:52AM -0700, Jan Pokorný wrote:

(have you figured out the subsequent versioning, yet?).

No, but I'd be more inclined to have 1.1 as the next version.
Unless we need to keep two released branches, but I hope not.

[dmuhamedagic]

The split looks interesting, and is certainly beneficial, but I'm still not entirely convinced whether the introduced complexity and multiple packages are worth it. IIRC, the positive side is not to enforce installing pacemaker & co on the arbitrator. I'm all for installing less software when not necessary, but increasingly have an impression that that view is not universally shared. People consider disk space cheap and apparently don't care how much of it gets used. Ditto for resources spent (wasted) on upgrades, etc. Is multiple packages better than just one? That seems to me to be a question verging on philosophical. I'm also not sure about how people actually operating data centres consider that, and if at all they do.