[RFC] Changes to open-source container versioning

20 views
Skip to first unread message

Morgan Rhodes

unread,
Oct 15, 2019, 6:56:49 PM10/15/19
to Puppet Users, Puppet Developers
Hi all,

tl;dr - We're trying to make the versioning scheme for our containers more intuitive, changes summarized in the table below, see more details at https://github.com/puppetlabs/puppetserver/pull/2188

build typecurrent tagnew tag
from sourcepuppet/puppetserver:6.7.0puppet/puppetserver:6.7
from source (latest)puppet/puppetserver:latestpuppet/puppetserver:edge
from packagen/apuppet/puppetserver:6.7.0
from package (latest)n/apuppet/puppetserver:latest
Versioning

For a while now, our containers have included a package built from source and versioned based on the most recent tag to the repo. While we still think building from source provides value to our users, it's become clear that they also need a way to pin to a specific, released version of puppetserver and count on that container not being updated. To address this, we're changing the versioning scheme for our container builds.

When we build images from source, those images will be versioned with X.Y versions based on the latest tag on master. So, for example, the current image versioned puppet/puppetserver:6.6.0 would move to puppet/puppetserver:6.6. This tag will continue to have rolling updates until the next X or Y release. If you want to follow whatever the latest version of the image from source is, you will want to pin to puppet/puppetserver:edge.

We will also start building and shipping images when puppetserver is shipped publicly. These images will be tagged with an X.Y.Z version that will match the version of puppetserver installed on that image. This tag will not receive any updates. If you want to follow the latest released version of puppetserver, you will want to pin to puppet/puppetserver:latest.

Other Changes for the puppetserver images

We are also looking into removing the puppetserver-standalone image. I've added a `USE_PUPPETDB` environment variable that can be set to false when running the puppetserver image to have the same behavior as the current puppetserver-standalone image.

Questions / Comments / Concerns?

Please leave comments at https://github.com/puppetlabs/puppetserver/pull/2188 or respond here.

--
Morgan Rhodes
Release Engineering
she/her/hers

A Manzer

unread,
Oct 16, 2019, 11:32:39 AM10/16/19
to Puppet Users
I find this scheme confusing.  I would be hard pressed to explain the difference between :6.7, built from source, and :6.7.0, built from a package.  I also don't think it's clear that :6.7 would advance past :6.7.0 in time.

I like the :edge and :latest tags.

But I think I'd be happier with some kind of "nightly" specification on the source version (unless I've misunderstood).  Maybe :6.7-nightly.  That would make it more clear to me that it's a frequent build of the 6.7 branch, while 6.7.0 is a pinned version.

On the whole though, I think it's a good change.  Thank you!

Morgan Rhodes

unread,
Oct 16, 2019, 9:44:27 PM10/16/19
to Puppet Users
On Wed, Oct 16, 2019 at 4:32 AM A Manzer <ama...@gmail.com> wrote:
I find this scheme confusing.  I would be hard pressed to explain the difference between :6.7, built from source, and :6.7.0, built from a package.  I also don't think it's clear that :6.7 would advance past :6.7.0 in time.

Is your confusion mostly around the fact that one of them is built from source and one from package, or that 6.7 is more of a floating tag? I know I've seen that pattern in some other upstream repos like centos, postgres, mysql, etc, but for those it might be 6.7 points to the latest 6.7.x that was shipped, rather than more like head/nightly.
 
--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3c910a1c-3e50-43ed-a554-57fceb48b7d1%40googlegroups.com.

Bart-Jan Vrielink

unread,
Oct 17, 2019, 8:51:44 AM10/17/19
to puppet...@googlegroups.com

Hello,


I'm equally confused. For almost all containers I'm used to, if the tag is just a version number, to me it indicates "built the same way as latest, but a fixed snapshot". If it is not built the same way as latest, I would expect the tag to include a label for that. So puppet/puppetserver:6.7-edge is more in line with other vendors of Docker images. This only for the first example in the table below, the others do make sense.



A Manzer

unread,
Oct 17, 2019, 12:01:59 PM10/17/19
to Puppet Users
On Wednesday, October 16, 2019 at 5:44:27 PM UTC-4, Morgan Rhodes wrote:

Is your confusion mostly around the fact that one of them is built from source and one from package, or that 6.7 is more of a floating tag? I know I've seen that pattern in some other upstream repos like centos, postgres, mysql, etc, but for those it might be 6.7 points to the latest 6.7.x that was shipped, rather than more like head/nightly.
 
It's mostly the from source, from package distiction.  I'm not familiar enough with Puppet's release cycle to know the distinction between a from source build and a from package build.  Are "from source" builds essentially just nightlys? I think people are more familiar with keywords such as "head", "master", "edge", or "nightly" and the tag should include something like that.  If they're not exactly nightly, but based on a tag in the source, what differentiates a from source build and a from package build?

If I were to look at these tags on Docker Hub, I'd expect them to represent the following:
puppet/puppetserver:6.7     => The latest release in the 6.7 series, moving from 6.7.0, through 6.7.1, etc.
puppet/puppetserver:6.7.0  => Exactly the release 6.7.0 and never changing
puppet/puppetserver:latest => The latest release of Puppet Server, moving through minor and major versions.  (Perhaps there's room for a puppet/puppetserver:6 tag here)
puppet/puppetserver:edge  => This one's less immediately obvious to me, but after a moment I'd probably realize that it was some kind of nightly or pre-release beta, especially given the tag date would be after the :latest tag.


Morgan Rhodes

unread,
Oct 17, 2019, 6:55:27 PM10/17/19
to Puppet Users
On Thu, Oct 17, 2019 at 1:51 AM Bart-Jan Vrielink <bar...@vrielink.net> wrote:

Hello,


I'm equally confused. For almost all containers I'm used to, if the tag is just a version number, to me it indicates "built the same way as latest, but a fixed snapshot". If it is not built the same way as latest, I would expect the tag to include a label for that. So puppet/puppetserver:6.7-edge is more in line with other vendors of Docker images. This only for the first example in the table below, the others do make sense.



Great, thank you for the feedback, that seems reasonable.
 

Morgan Rhodes

unread,
Oct 17, 2019, 7:10:36 PM10/17/19
to Puppet Users
On Thu, Oct 17, 2019 at 5:02 AM A Manzer <ama...@gmail.com> wrote:
On Wednesday, October 16, 2019 at 5:44:27 PM UTC-4, Morgan Rhodes wrote:

Is your confusion mostly around the fact that one of them is built from source and one from package, or that 6.7 is more of a floating tag? I know I've seen that pattern in some other upstream repos like centos, postgres, mysql, etc, but for those it might be 6.7 points to the latest 6.7.x that was shipped, rather than more like head/nightly.
 
It's mostly the from source, from package distiction.  I'm not familiar enough with Puppet's release cycle to know the distinction between a from source build and a from package build.  Are "from source" builds essentially just nightlys? I think people are more familiar with keywords such as "head", "master", "edge", or "nightly" and the tag should include something like that.  If they're not exactly nightly, but based on a tag in the source, what differentiates a from source build and a from package build?

The "from source" builds aren't quite nightlies, since they get built on every commit/PR into master, so depending on how much development is happening it could end up built more often, and there's certainly more risk of picking up bugs.

In this model the source builds aren't built based on a tag. We use `git describe` to come up with the tag for the container, but the code is from head/master.

If I were to look at these tags on Docker Hub, I'd expect them to represent the following:
puppet/puppetserver:6.7     => The latest release in the 6.7 series, moving from 6.7.0, through 6.7.1, etc.
puppet/puppetserver:6.7.0  => Exactly the release 6.7.0 and never changing
puppet/puppetserver:latest => The latest release of Puppet Server, moving through minor and major versions.  (Perhaps there's room for a puppet/puppetserver:6 tag here)
puppet/puppetserver:edge  => This one's less immediately obvious to me, but after a moment I'd probably realize that it was some kind of nightly or pre-release beta, especially given the tag date would be after the :latest tag.

Do you have a feel for whether or not it would be valuable to have a `6.7-edge` in addition to `edge`, where `6.7-edge` would be HEAD of master from the time 6.7.0 is tagged until the last commit before 6.8.0 is pushed? Thinking about it more it might make sense to just have `edge` as the latest from-source build and save the more granular/versioned tags for builds from packages.
 


--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

A Manzer

unread,
Oct 17, 2019, 8:02:54 PM10/17/19
to Puppet Users
On Thursday, October 17, 2019 at 3:10:36 PM UTC-4, Morgan Rhodes wrote:
The "from source" builds aren't quite nightlies, since they get built on every commit/PR into master, so depending on how much development is happening it could end up built more often, and there's certainly more risk of picking up bugs.

In this model the source builds aren't built based on a tag. We use `git describe` to come up with the tag for the container, but the code is from head/master.

This makes sense, thanks. It's close-ish to a nightly. :-)

Do you have a feel for whether or not it would be valuable to have a `6.7-edge` in addition to `edge`, where `6.7-edge` would be HEAD of master from the time 6.7.0 is tagged until the last commit before 6.8.0 is pushed? Thinking about it more it might make sense to just have `edge` as the latest from-source build and save the more granular/versioned tags for builds from packages.

Sure!  Tags are free right?  Maybe there's something in 6.8 that someone doesn't want so they'll stick to 6.7.  Or maybe someone wants to test the 6.7 stream beginning to end, which might overlap with the 6.8 stream which they want to test too.  Or maybe there will be a security update to 6.7 after you start work on 6.8, so both will be going at once.  I think there's value in:
`6`
`6-edge`
`6.7` (or maybe even `6.7-latest`)
`6.7-edge`
`6.7.2`
`latest`
`edge`

Morgan Rhodes

unread,
Oct 17, 2019, 8:08:36 PM10/17/19
to Puppet Users
Thanks for the feedback! 

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages