[Debian-ha-maintainers] Split of HA agents into multiple binary packages

[Lucas Kanashiro]

Hi Ferenc,

Thanks for joining the discussion :)

Em 29/03/2023 07:36, Ferenc Wágner escreveu:
> Hi Lucas and Valentin,
>
> I'm sorry for being this late to the party.  You gathered substantial
> content in this thread, let me try to condense it to gain better
> overview.
>
> First, some points seem to require further clarification:
>
> - If I understand Lucas correctly, some fence agents don't work after
>    installation due to missing dependencies.  Could you please provide
>    the concrete examples?  This would be good and easy to fix.
>    On the other hand the resource agent packages obviously can't depend
>    on all the managed components in the current setup.

I am changing my proposal now to only split the fence-agents package and 
keep resource-agents as is. After analyzing better I believe we should 
definitely follow RedHat here.

Some concrete cases of dependencies that are missing:

- fence_amt should depend on amtterm.

- fence_gce should depend on python3-googleapi (or python3-oauth2client).

- fence_heuristics_ping should depend on iputils-ping.

- fence_ilo2 should depend on python3-xmlschema and gnutls-bin apparently.

- fence_ipmilan should depend on ipmitool.

- fence_kubevirt should depend on python3-openshift (which will pull in 
python3-kubernetes).

- fence_mpath should depend on multipath-tools.

- fence_openstack should depend on python3-yaml.

- fence_sbd should depend on sbd.

- fence_virsh should depend on libvirt-clients.

It does not mean that all those dependencies should be in Depends but 
they should be have some kind of relationship with the package.

> - Is the reverse also a significant problem?  How much content does the
>    current monolithic fence-agents package install?  It's quite small in
>    itself, but there can be big dependencies.  Here I wouldn't consider
>    Python, though, since it's widely installed anyway.

Well, in the list I presented above you can see some non-python packages 
and some of them might be considered too much for a sysadmin if they do 
not want to use the agent depending on that. And here I am not talking 
about disk space but increasing the possible attack surface in the server.

I do not have a very precise number regarding disk space to give you but 
the non-python packages above would result in more or less 2MB.

> There are some clear advantages of splitting fence-agents:
>
> - consistency with Fedora/Red Hat
>
> - installing only the explicitly requested fence agents

+1

> There are some not-so-clear points:
>
> - simpler setup (How exactly?  Cluster setup is often done with Ansible
>    or some similar tool anyway.)

Even using Ansible or any software to write infrastructure as code, 
devops/sysadmin people always try to install just what is needed for 
they use case, to reduce attack surface and so on. With my proposal, we 
would be able to attend users that want to keep it as is (with a fat 
binary package shipping everything, in this case a metapackage) and 
users willing to have a more fine-grained environment and control what 
is installed and the purpose.

> - space savings (Possibly insignificant, see second question above.)

As you can see in my reply above, I do not think this is too significant.

> - better user experience (We don't know of any user requests or reports.)

In Ubuntu I have seen some comments flying by, maybe in Debian we do not 
have any track of that because our users are already used to this way 
and might have everything correctly set for their use cases. My point 
is: we need to be able to reach users that we might not have reached so 
far and, of course, keep our current users satisfied. That is my proposal.

> While there are also reasons against the split:
>
> - even Fedora/Red Hat does not split resource-agents

Agreed. Let's remove this from the proposal.

> - consistency between fence- and resource-agents packages

I tried to explain this in my initial email but I am not sure if it was 
clear enough. Those have different nature: fence-agents will be executed 
in a remote node (not the one that is actually running the service or 
whatever), so it requires to depend on everything that is needed to 
execute this script with success; on the other hand, resource-agents 
will be executed where the managed resource is running so all the 
dependencies will likely be there, moreover, the majority of the scripts 
are written in bash which does not require more dependencies.

Due to that, I believe we should manage them differently as RedHat is 
doing.

> - consistency with current Debian practice

For me, one important principle in Debian is to try to make things work 
out-of-the-box, that is not what is happening right now. We are relying 
on the expertise of our users to write their Ansible playbooks (or 
whatever they use) correctly, to figure out and install the needed 
dependencies.

> - hundreds of binary packages would be significantly harder to maintain
>    than two

Agreed. But we should not give up on improving because it will make our 
life harder, I prefer to think on the benefits our users will have with 
the proposed changes. I volunteer myself to help with any unpleasant 
work that might come up out of this.

> - requires FTP master involvement on agent set changes (after a quick
>    look that's 1 in 2022, but at least 3 in 2021)

This is a workable number for me, I can poke them (multiple times :) 
whenever you need. And for removals it is much easier.

> - impossible to co-install two web-server resource agents if they pulled
>    their servers with default configs, since they couldn't both start, so
>    the resource-agent meta-package wouldn't work

You are right. I gave up on this part of the proposal.

> - strict dependencies would unnecessarily pull in server packages when
>    managing self-compiled servers

Yes, managing self-compiled/third-party servers seems to be a common use 
case, so let's not force installation of anything for resource-agents.

> Please add more points if needed, I probably haven't grasped everything
> and may have misinterpreted some arguments.  Based on the above I'd be
> wary to change the design, but further input to the above questions may
> tip the balance.
Thank you very much for spending the time reading and summarizing what 
we have discussed so far. I hope my comments have helped to change your 
mind a bit :) I really believe the benefits would be greater than the 
mentioned disadvantages.

I am here to help with whatever is needed!

Thank you all for the attention.

-- 
Lucas Kanashiro