Unsatisfiable recommended dependencies pacemaker >= 2.0, corosync >= 3.0

[Ben Fu]

[Impact]
pcs can't be used for pacemaker and corosync in Disco

[Description]
In Disco, it looks like pcs was updated to version 0.10 without an accompanying update to pacemaker and corosync. From the pcs-0.10 changelog [0]:
- Pcs-0.10 removes support for CMAN, Corosync 1.x, Corosync 2.x and Pacemaker 1.x based clusters. For managing those clusters use pcs-0.9.x.

Looking at the current versions for corosync and pacemaker in Disco, we can see that they are not supported by this pcs version:

$ rmadison -a amd64 corosync | grep disco
 corosync | 2.4.4-3 | disco | amd64

$ rmadison -a amd64 pacemaker | grep disco
 pacemaker | 1.1.18-2ubuntu1 | disco | amd64
 pacemaker | 1.1.18-2ubuntu1.19.04.1 | disco-security | amd64
 pacemaker | 1.1.18-2ubuntu1.19.04.1 | disco-updates | amd64

Instead of upgrading pacemaker and corosync, with the risk of introducing lots of untested issues, we should consider rolling pcs back to an already tested version such as 0.9.x.

[0] https://github.com/ClusterLabs/pcs/blob/master/CHANGELOG.md#0101---2018-11-23

[Test Case]
Try to install pacemaker and pcs at the same time in Disco:

root@disco:~# apt install pacemaker pcs
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 pcs : Breaks: pacemaker (< 2.0) but 1.1.18-2ubuntu1.19.04.1 is to be installed
       Recommends: pacemaker (>= 2.0) but 1.1.18-2ubuntu1.19.04.1 is to be installed
E: Unable to correct problems, you have held broken packages.

[Regression Potential]
The regression potential should be low, as long as we correctly roll pcs back to a previously tested version. Since corosync/pacemaker packages were not updated, this shouldn't introduce any new regressions. We'll do diligent testing with autopkgtest for any other problems.

# # # #

[Original Description]
The current version of pcs in disco is 0.10.x, which requires pacemaker >= 2.0 and corosync >=3.0, neither of which are available yet. Should the version be downgraded to 0.9.x until the other packages are updated?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robie Basak (racb)]

Thank you for working on this.

I was curious to understand why proposed migration didn't block this change from hitting the release pocket. Is there a missing dependency somewhere? For example:

> The current version of pcs in disco is 0.10.x, which requires pacemaker >= 2.0 and corosync >=3.0, neither of which are available yet.

If this statement is true, then why isn't there a dependency declaring this, which would (I'm assuming) have prevented this situation from arising?

[Eric Desrochers (slashd)]

At first I thought it has something to do with the use of 'Recommends: pacemaker (>= 2.0)' which is not as strong/powerful as 'Depends:'

but still, there is a 'Breaks: pacemaker (<< 2.0)' which make the binary package uninstallable, proposed migration should detect that right ?

Additionnally, debian/test/control (AKA autopkgtest) relies on pacemaker (<=2.0) too, so how autopkgtest could have passed and switch the package to a 'Valid Candidate' state without meeting the requirements.

Clearly, the autopkgtest failed too:
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/amd64/p/pcs/20190411_115307_7ea26@/log.gz
...
Broken autopkgtest-satdep:amd64 Depends on pacemaker:amd64 < none | 1.1.18-2ubuntu1 @un uH > (>= 2.0)
  Removing autopkgtest-satdep:amd64 because I can't find pacemaker:amd64
...
badpkg: Test dependencies are unsatisfiable. A common reason is that your testbed is out of date with respect to the archive, and you need to use a current testbed or run apt-get update or use -U.
testsuite-ruby PASS
testsuite-python FAIL badpkg

Or does straight copy from Debian has a special path ? because 'pcs' is a copy from debian.

https://launchpad.net/ubuntu/+source/pcs/+publishinghistory
2019-01-19 08:08:17 EST Published Disco release universe misc 0.10.1-2
Copied from debian sid in Primary Archive for Debian GNU/Linux by Ubuntu Archive Auto-Sync (sponsored by Ubuntu Archive Robot)

I'm puzzled about what happened here and how/why this and in -relese pocket, knowing that:

- autopkgtest requirement aren't meet.
- binary package is not installable.

For now, I think we need :

1) To come to a conclusion about what is the next action plan to fix Disco (based on Heitor's proposals)
2) Maybe suggest to debian a change to replace 'Recommends:' to 'Depends:' in d/control to make the declaration more strict/stronger.
3) Try to understand what happened to make sure this won't re-occur in the archive in the future.

Thoughts ?

- Eric

[Robie Basak (racb)]

On Tue, May 28, 2019 at 01:30:48PM -0000, Eric Desrochers wrote:
> At first I thought it has something to do with the use of 'Recommends:
> pacemaker (>= 2.0)' which is not as strong/powerful as 'Depends:'

Looking deeper, I think this is it. It's perfectly possible (as far as
apt is concerned) to install pcs without installing pacemaker. Ask for
both together however and apt refuses. From a packaging perspective this
is fine - there are plenty of package sets in the distribution that are
not co-installable (eg. those that directly Conflict). So that's why it
will have passed the installability check.

The reason the autopkgtest result was ignored was the following:

https://bazaar.launchpad.net/~ubuntu-sru/britney/hints-ubuntu-disco/revision/3469

...which did:

-force-badtest pcs/0.9.164-1 pcs/0.9.166-2 pcs/0.9.166-5
+force-badtest pcs/0.9.166-5 pcs/0.10.1-2

...which was wrong.

Is there any circumstance where a user might find installing pcs without
pacemaker a useful thing to do? If not, then perhaps it should be a
Depends. If there is some circumstance in which it's generally OK, then
I guess we need to rely on autopkgtest and not hinting it incorrectly.

[Eric Desrochers (slashd)]

I don't think so, seems like 'pcs' is the 'Pacemaker Configuration System'.
I can't see how 'pcs' can be useful outside the pacemaker/corosync context.

Reference:
----------
https://github.com/ClusterLabs/pcs

PCS - Pacemaker/Corosync Configuration System
Pcs is a Corosync and Pacemaker configuration tool. It permits users to easily view, modify and create Pacemaker based clusters. Pcs contains pcsd, a pcs daemon, which operates as a remote server for pcs and provides a web UI.
----------

I think it's safe to add a 'Depends:'.

[Eric Desrochers (slashd)]

Oh maybe 'pcs' can be operated from a remote server for pcs and provides a web UI.

In this case, maybe pacemaker is not 'needed' all the time.

I'm not a 'pcs' expert here, but yeah maybe this is why 'Recommends:' has been picked.

[Heitor Alves de Siqueira (halves)]

Even in the case that you are operating on a remote server, the remote pcsd client needs pacemaker/corosync scripts. Without that, even the very basic commands won't work:

ubuntu@disco:~$ pcs status
Error: unable to run command crm_mon --one-shot --inactive: No such file or directory: 'crm_mon'
ubuntu@disco:~$ pcs cluster status
No such file or directory: '/usr/sbin/crm_mon'
Error: unable to locate command: /usr/sbin/crm_mon
ubuntu@disco:~$ pcs resource status
No such file or directory: '/usr/sbin/crm_mon'
Error: unable to locate command: /usr/sbin/crm_mon
ubuntu@disco:~$ pcs acl
Error: unable to run command /usr/lib/pacemaker/pacemaker-schedulerd metadata: No such file or directory: '/usr/lib/pacemaker/pacemaker-schedulerd'
ubuntu@disco:~$ pcs property list
No such file or directory: '/usr/sbin/cibadmin'
Error: unable to locate command: /usr/sbin/cibadmin
ubuntu@disco:~$ pcs config
No such file or directory: '/usr/sbin/cibadmin'
Error: unable to locate command: /usr/sbin/cibadmin
Cluster Name:
No such file or directory: '/usr/sbin/crm_mon'
Error: unable to locate command: /usr/sbin/crm_mon
ubuntu@disco:~$ pcs alert
Alerts:
Error: unable to run command /usr/sbin/cibadmin --local --query: No such file or directory: '/usr/sbin/cibadmin'

ubuntu@disco:~$ dpkg -S /usr/sbin/crm_mon
pacemaker-cli-utils: /usr/sbin/crm_mon
ubuntu@disco:~$ dpkg -S /usr/sbin/cibadmin
pacemaker-cli-utils: /usr/sbin/cibadmin

As you need the pcsd client running in all remote servers that you want to manage through pcs, we would bump into this issue again on each remote host, even if pacemaker is not needed in the local admin machine.
Imho (humble), it makes little sense to have pcs installed without pacemaker. It doesn't seem to work at all without the underlying pacemaker tools.

[Eric Desrochers (slashd)]

Going back to my previous list:

1) To come to a conclusion about what is the next action plan to fix Disco (based on Heitor's proposals)
2) Maybe suggest to debian a change to replace 'Recommends:' to 'Depends:' in d/control to make the declaration more strict/stronger.
3) Try to understand what happened to make sure this won't re-occur in the archive in the future.

Seems like 2) and 3) are now covered, we just need to come to an agreement about what we do next with Disco for 1).

[Robie Basak (racb)]

On Tue, May 28, 2019 at 07:31:16PM -0000, Eric Desrochers wrote:
> Seems like 2) and 3) are now covered, we just need to come to an
> agreement about what we do next with Disco for 1).

A quick drive by comment wearing my SRU hat in case it helps:

If the package is really completely broken and there are no reasonable
use cases for the pcs package in Disco currently that work, then I'm
confident that the entire SRU team would agree that some more radical
fix, such as downgrading the package in the updates pocket, might be OK.

[Dan Streetman (ddstreet)]

see also related corosync bug 1831492