Molecule: Quay tags: stable/latest/pre-release etc.

Created on 11 Mar 2019  路  14Comments  路  Source: ansible-community/molecule

Please see https://quay.io/repository/ansible/molecule?tab=tags.

Our latest tag current points to the latest build IIUC. See https://github.com/ansible/molecule/issues/1813#issuecomment-471504129.

I'm unfamiliar with conventions for the latest tag but should it be latest 'stable', and point to v2.19?

See https://github.com/ansible/molecule/issues/1813#issuecomment-471476378.

My intuition is:

  • stable -> v2.19 (or latest stable release)
  • vX.Y -> pre-release versions for pre-release hacking / feedback / early testing
  • latest -> convenience for latest build (and potentially dangerous to target)

I'm easy and just want to agree on this so we can be clear what tag is what.

bug docs

Most helpful comment

Hi, sure, if you need to help with maintaining anything, contact me. I will like to contribute to this project :-).

All 14 comments

The molecule tradition was: publish a docker image only at release time, so latest has always been latest stable. But as we are in a big revamp, and ppl have to move to quay anyway, this is the right moment to change. For example I believe it would be fairly convenient to tag a "stable" image which would be latest stable, and a "latest" image built upon maste. Maybe also a "test" image for the prereleases. We should carefully communicate about this change.

Even better, maybe we should provide a docker image for each supported version of ansible (we surely can skip a dedicated version per python version). Something like:

molecule:stable-ansible-2.7

Would that be Ansible 2.7.0 or should it be re-built for every patch release? I personally would prefer to have the latest released version of Ansible at the time the molecule version was released in there, not much more.

About stable/latest/vX.Y --> since docker unfortunately defaults to "latest", I'd make sure that this is the latest stable release, daily builds or build per commit or alpha versions etc. can have their own tags.

In the longer run I'd expect to see one tag with each released version on there, one for each branch (e.g. I'd expect the "master" tag to contain the code of the most recent commit of the "master" branch here) and "latest" pointing to the latest stable release.

Docker tradition is to have latest point to unstable things. Using "latest" is usually equivalent of not pinning dependencies of the environment which is a generally discouraged practice in software development and deployment world.
Whatever we choose we should clearly state that it's recommended to point to a numeric version whenever using the image for anything other than experimenting.
But pointing latest to stable we'd kinda encourage people to use it which is not kind of messaging I'd like to see.

https://hub.docker.com/_/ubuntu --> ubuntu:latest points to 18.04 LTS, not 18.10 (latest released version) or 19.04 (latest unstable version).

I'd be more than happy to not tag any image as "latest" to make sure users are actively choosing a release or a "rolling update" tag.

So we hare facing multiple docker traditions.

Maybe we can look at the option to stick to what we already have:

First, we have the organization of the git repository:

  • the master branch is the only alive branch in the repository -> one rolling docker master tag following this branch.
  • each released version (including pre-releases) has a tag in git -> one immutable docker tag for each git tag.

Then, main distribution is done via pip.
pip has the notion of stable and pre-release versions and can follow upgrade on both channels (https://pip.readthedocs.io/en/stable/reference/pip_install/#pre-release-versions)

  • one rolling docker stable version following the latest stable pip release
  • one rolling docker pre-release version following the latest pre-release pip release

In this scheme there are 3 tags designing non-immutable versions: master, stable, pre-release.
Of course with this scheme a user need to be specific about which channel to follow.

There is no latest in this scheme, so no question of which docker tradition we are supposed to follow. A quick search on random project on quay showed that projects without a latest tag are not unusual.

@themr0c the problem is that when you type docker run image-name it uses latest implicitly which would lead to confusion when it will report to users that "there's no such thing". That's why I'd like latest to point to master.

WRT to pre-release, let's refer to PEP 440 directly which pip is relying on.

I upvote idea of having docker images with multiple stable ansible versions (or maybe also unreleased new major version) in tags. I know there are people with ansible version constraints. It would be also nice to be able to test molecule with latest unreleased version of ansible (2.8) to continuously test ansible version upgrade.

Imagine situation, where you are running ansible 2.7, then new release comes out, you update docker image to ansible 2.8, and the CIs of people are failing because of this.

To the latest tag I can see, that for Nginx, it is the latest docker repository commit, which downloads latest release.

Imagine situation, where you are running ansible 2.7, then new release comes out, you update docker image to ansible 2.8, and the CIs of people are failing because of this.

That would be a regression, we usually don't introduce unexpected breaking changes to _stable_ interfaces without a deprecation warning during several versions.

So more realistic would be people updating from 2.3 to 2.8. Another good example would be people not reading docs and assuming that interfaces marked as technical preview will stay the same forever :)

It's probably possible to ship multiple combos of Ansible+Molecule versions. But the support matrix would grow big. @Lirt are you ready to step up and take over maintaining this part of the project making sure it keeps being well-covered? Human resources are limited and we always need a lot of help so you're welcome to join :)

Btw, we talked about this during https://meetbot.fedoraproject.org/ansible-molecule/2019-03-13/ansible_molecule_working_group.2019-03-13-19.00.html and we agreed on:

AGREED: latest is latest release, devel is latest devel build, tagged (in git) releases and prereleases get tags

IIRC, @gundalow will be taking care of this.

Hi, sure, if you need to help with maintaining anything, contact me. I will like to contribute to this project :-).

@Lirt feel free to participate: https://github.com/ansible/community/issues/427.

OK, we're making progress in this regard but it's still a bit here and there. Please see https://github.com/ansible/molecule/pull/1838 to see what currently agreed on. The most important part for right now (2.20 release urgency) is that we offer a stable numbered release tag that users can depend on. "latest"/"devel" and friends remain defined (but there has been some disagreement). I'm going to close this off for now.

Was this page helpful?
0 / 5 - 0 ratings