Poki,

Could you shed light on the situation described in Additional info - newer booth in RHEL 7 than in RHEL 8? What are the plans for RHEL 8 booth?

Thanks.

@Reid:
Thank you for the notice, this one is assigned to pcs, so I overlooked it (and it wasn't assigned to me).

Situation with booth versioning is kind of complicated, so let me explain it in a more details.

Upstream-vise, it is simple. Last released version is 1.0. Every other patch on top of 1.0 is just in upstream git.

Downstream is more complicated. We have to keep main version 1.0. So that is why in all RHEL and Fedora version is booth version booth-1.0-SOMETHING.git.%{dist}.release_tag.

The SOMETHING is actually consisted of "specver" variable, which must be increased to guarantee upgradability, followed by SHA1 git hash shortened to 7 characters.

release_tag is either auto added/increased on rebuild or when adding patch without rebasing.

Of course on rebased it's needed to increase specver.

So, the important number is actually not that much "specver" but rather SHA1 and release_tag.

Does it make sense?

I'm not sure if I was able to describe booth versioning clearly, but no matter what, it is overcomplicated and prone to problems you've described (upgrade from RHEL 7 -> RHEL 8).

I was thinking about scheme based on git describe, so basically booth-1.0-(PATCHES_SINCE_1.0).(RELEASE_TAG).(SHA1).git.%{dist) - or swap RELEASE_TAG and SHA1, not sure which one would look nicer, probably the later one.

That would allow us to:
- Easily compare two non-rebased versions - RELEASE_TAG increases, nothing else changes
- Easily compare two rebased versions - PATCHES_SINCE_1.0 increase. RELEASE_TAG resets to 1. SHA1 differs.
- Remove release_tag at the end of the rpm (example for current Fedora - booth-1.0-6.ac1d34c.git.fc33.3.src.rpm, this look like fc33 has a Z stream).

Does it make sense? What do you think?

@Reid:
Oh, I've forgot to answer one of your questions. Actually even RHEL 8.0.0 is newer (f2d38ce3d61502bda2a28e79db103737a691faf4 = v1.0-144-gf2d38ce = 144 patches on top of 1.0) than RHEL 7.9 (ef769ef9614e8446f597ee4d26d5d339a491ab2f = v1.0-104-gef769ef = 104 patches on top of 1.0).

manual ticket mode is probably really problem of pcs, because booth (current master - v1.0-220-g69cf659) supports manual tickets just fine.

Hi, Honza. Sorry for my late response.

(In reply to Jan Friesse from comment #3)
> The SOMETHING is actually consisted of "specver" variable, which must be
> increased to guarantee upgradability, followed by SHA1 git hash shortened to
> 7 characters.
> 
> release_tag is either auto added/increased on rebuild or when adding patch
> without rebasing.
> 
> Of course on rebased it's needed to increase specver.
> 
> So, the important number is actually not that much "specver" but rather SHA1
> and release_tag.
> 
> Does it make sense?

Mostly, yes. The unclear parts are probably due to my vague understanding of the Red Hat packaging and release process in general.

In particular, I don't really understand when release_tag would be incremented **without** specver being incremented (or vice-versa). In other words, what kind of change/rebuild would bump one but not the other. Does a specver increase **without** a release_tag increase, indicate that the RPM spec was updated but the source code was not?

"on rebased it's needed to increase specver." <- but the 1.0 tag hasn't been updated in four and a half years, yet the specver has increased since then.

The RHEL 8 releases are as follows. The specver, release_tag, and SHA were all updated during the one package update.
1.0-6.ac1d34c.git.el8.2
1.0-5.f2d38ce.git.el8

The RHEL 7 releases are as follows. In all three updates, the specver was incremented, the SHA stayed the same, and there was no release_tag (implicit "1" I guess).
1.0-8.ef769ef.git.el7
1.0-7.ef769ef.git.el7
1.0-6.ef769ef.git.el7

---
 
> I'm not sure if I was able to describe booth versioning clearly, but no
> matter what, it is overcomplicated and prone to problems you've described
> (upgrade from RHEL 7 -> RHEL 8).

In addition to the counter-intuitive appearance of the current versioning scheme, Package Browser incorrectly shows the RHEL 7 version as being the latest due to its version number.

https://access.redhat.com/downloads/content/booth-core/1.0-8.ef769ef.git.el7/x86_64/fd431d51/package

---

> I was thinking about scheme based on git describe, so basically
> booth-1.0-(PATCHES_SINCE_1.0).(RELEASE_TAG).(SHA1).git.%{dist) - or swap
> RELEASE_TAG and SHA1, not sure which one would look nicer, probably the
> later one.
> 
> That would allow us to:
> - Easily compare two non-rebased versions - RELEASE_TAG increases, nothing
> else changes
> - Easily compare two rebased versions - PATCHES_SINCE_1.0 increase.
> RELEASE_TAG resets to 1. SHA1 differs.
> - Remove release_tag at the end of the rpm (example for current Fedora -
> booth-1.0-6.ac1d34c.git.fc33.3.src.rpm, this look like fc33 has a Z stream).
> 
> Does it make sense? What do you think?

Would we still need the SHA1 at all if we go with this approach? Most of our package release strings don't include SHA1's. It seems that "PATCHES_SINCE_1.0" would act as a sort of unique identifier.

---

> manual ticket mode is probably really problem of pcs, because booth (current master - v1.0-220-g69cf659) supports manual tickets just fine.

Yes, based on the explanation you've given, I agree with that assessment.

Originally, I hadn't checked master, because I had assumed that 1.0.8 was newer than 1.0.5.

(In reply to Reid Wahl from comment #5)
> Hi, Honza. Sorry for my late response.
> 
> (In reply to Jan Friesse from comment #3)
> > The SOMETHING is actually consisted of "specver" variable, which must be
> > increased to guarantee upgradability, followed by SHA1 git hash shortened to
> > 7 characters.
> > 
> > release_tag is either auto added/increased on rebuild or when adding patch
> > without rebasing.
> > 
> > Of course on rebased it's needed to increase specver.
> > 
> > So, the important number is actually not that much "specver" but rather SHA1
> > and release_tag.
> > 
> > Does it make sense?
> 
> Mostly, yes. The unclear parts are probably due to my vague understanding of
> the Red Hat packaging and release process in general.
> 
> In particular, I don't really understand when release_tag would be
> incremented **without** specver being incremented (or vice-versa). In other

That's the problem. specver is actually invention of previous booth maintainer. But I was increasing release_ver when adding patch or doing rebuild, without doing rebase (mostly for Fedora master, so you've probably haven't had chance to see that).

> words, what kind of change/rebuild would bump one but not the other. Does a
> specver increase **without** a release_tag increase, indicate that the RPM
> spec was updated but the source code was not?

Yes, I believe that was the idea.

> 
> "on rebased it's needed to increase specver." <- but the 1.0 tag hasn't been
> updated in four and a half years, yet the specver has increased since then.

Yes. Because upstream latest release is 1.0. We are rebasing on top of (unreleased) git archives. Another approach would be to include (currently) 226 patches in distgit - probably not too great idea.

> 
> The RHEL 8 releases are as follows. The specver, release_tag, and SHA were
> all updated during the one package update.
> 1.0-6.ac1d34c.git.el8.2
> 1.0-5.f2d38ce.git.el8

Yup, because I've did upgrade.

Side note - plese , notice the el8.2 postfix. It looks like it is ZStream for 8.2, but actually it isn't. This is why I'm suggesting different versioning schema.

> 
> The RHEL 7 releases are as follows. In all three updates, the specver was
> incremented, the SHA stayed the same, and there was no release_tag (implicit
> "1" I guess).
> 1.0-8.ef769ef.git.el7
> 1.0-7.ef769ef.git.el7
> 1.0-6.ef769ef.git.el7

Really cannot say why it has happened.

> 
> ---
>  
> > I'm not sure if I was able to describe booth versioning clearly, but no
> > matter what, it is overcomplicated and prone to problems you've described
> > (upgrade from RHEL 7 -> RHEL 8).
> 
> In addition to the counter-intuitive appearance of the current versioning
> scheme, Package Browser incorrectly shows the RHEL 7 version as being the
> latest due to its version number.
> 
> https://access.redhat.com/downloads/content/booth-core/1.0-8.ef769ef.git.el7/
> x86_64/fd431d51/package

Indeed and it is quite a big problem. That's why I've suggested new versioning scheme, which would solve this problem by updating to version 1.0-226 so RHEL 8 would be bigger than RHEL 7.


> 
> ---
> 
> > I was thinking about scheme based on git describe, so basically
> > booth-1.0-(PATCHES_SINCE_1.0).(RELEASE_TAG).(SHA1).git.%{dist) - or swap
> > RELEASE_TAG and SHA1, not sure which one would look nicer, probably the
> > later one.
> > 
> > That would allow us to:
> > - Easily compare two non-rebased versions - RELEASE_TAG increases, nothing
> > else changes
> > - Easily compare two rebased versions - PATCHES_SINCE_1.0 increase.
> > RELEASE_TAG resets to 1. SHA1 differs.
> > - Remove release_tag at the end of the rpm (example for current Fedora -
> > booth-1.0-6.ac1d34c.git.fc33.3.src.rpm, this look like fc33 has a Z stream).
> > 
> > Does it make sense? What do you think?
> 
> Would we still need the SHA1 at all if we go with this approach? Most of our

Yes, you are right, it wouldn't be needed, but it is recommended for git archive based versions to contain SHA1 hash.

> package release strings don't include SHA1's. It seems that

This all comes from using git archives, because upstream hasn't released the new version since 16 Mar 2016. All other packages in HA repository is under our control directly and we do release new versions regularly.

 
> "PATCHES_SINCE_1.0" would act as a sort of unique identifier.
> 
> ---
> 
> > manual ticket mode is probably really problem of pcs, because booth (current master - v1.0-220-g69cf659) supports manual tickets just fine.
> 
> Yes, based on the explanation you've given, I agree with that assessment.
> 
> Originally, I hadn't checked master, because I had assumed that 1.0.8 was
> newer than 1.0.5.

Yeah, it is pretty confusing. But I do believe we are on same page there, so I will give the new schema a try in Fedora for a while and will try to rebase (or at least change versioning schema) for RHEL 8.4

Cloned to bug 1873948 for booth component to solve inconsistent package versioning.

Upstream patch:
https://github.com/ClusterLabs/pcs/commit/0a48111df5d2fd12008ea828656408ff94266476

See comment 0 for test / reproducer

DevTestResults:

[root@r8-node-01 ~]# rpm -q pcs
pcs-0.10.13-1.el8.x86_64

[root@r8-node-01 ~]# pcs booth setup sites 127.0.0.{1..3}
[root@r8-node-01 ~]# pcs booth config
authfile = /etc/booth/booth.key
site = 127.0.0.1
site = 127.0.0.2
site = 127.0.0.3
[root@r8-node-01 ~]# pcs booth ticket add Ticket mode=mode
Error: 'mode' is not a valid mode value, use 'auto', 'manual', use --force to override
Error: Errors have occurred, therefore pcs is unable to continue
[root@r8-node-01 ~]# pcs booth ticket add TicketA mode=manual
[root@r8-node-01 ~]# pcs booth ticket add TicketB mode=auto
[root@r8-node-01 ~]# pcs booth config
authfile = /etc/booth/booth.key
site = 127.0.0.1
site = 127.0.0.2
site = 127.0.0.3
ticket = "TicketA"
  mode = manual
ticket = "TicketB"
  mode = auto

Additional patch for making the mode value case insensitive, tests are included: https://github.com/ClusterLabs/pcs/commit/000e54f9c21456f89599830779b7e85b2cc7d0f8

DevTestResults:

[root@r8-node-01 ~]# rpm -qa pcs booth*
booth-core-1.0-199.1.ac1d34c.git.el8.x86_64
pcs-0.10.14-2.el8.x86_64
booth-site-1.0-199.1.ac1d34c.git.el8.noarch
booth-1.0-199.1.ac1d34c.git.el8.x86_64

[root@r8-node-01 ~]# pcs booth setup sites 127.0.0.{1..3}
[root@r8-node-01 ~]# pcs booth config
authfile = /etc/booth/booth.key
site = 127.0.0.1
site = 127.0.0.2
site = 127.0.0.3
[root@r8-node-01 ~]# pcs booth ticket add TicketA mode=MANUAL
[root@r8-node-01 ~]# pcs booth ticket add TicketB mode=AutO
[root@r8-node-01 ~]# pcs booth config
authfile = /etc/booth/booth.key
site = 127.0.0.1
site = 127.0.0.2
site = 127.0.0.3
ticket = "TicketA"
  mode = manual
ticket = "TicketB"
  mode = auto

Adding release note text that was approved for RHEL 9 ini this BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=2058243

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: pcs security, bug fix, and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:7447