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.