Airship - Multi-OS: image builds - repository per distributive
Hello everyone,
We have had a few discussions previously and now have an approved spec [0] and a story [1] (many thanks to James Gu) which will help us to make Airship work with (on) various Linux distributives.
One of the first steps towards implementation of the above mentioned specification is an in-progress effort to support OpenSUSE as a base image for Airship components containers. This has started as a set of patches under `airship_suse` Gerrit topic [2] (many thanks to Arun Kant).
During the work on this patches, it has become clear that we would need to formalize the way we would build and publish images which are based on different distributives. To help with that I have created a PS [3] to set some rules on image builds & publishing, and left it for a discussion.
Discussion [3] has shown, that we have controversial opinions on implementation details. On a latest IRC meeting we have had I've volunteered to move the discussion onto the Airship community discussions mailing list (this one). This has been done: - to reach wider audience, collect more opinions and reasoning both in ML and in PS, - to collectively come to the conclusion and agreement on implementation details, - to reflect decision in a PS [3] and get it merged to the specification [0], - and then use specification [0] as a guidance for implementation ([2] and others in the future)
The topic and opinions are the following:
Topic Statement: Non-Ubuntu container images repository naming convention is to add a dash separator, following with a distributive flavour, optionally specifying version after dash: ``airshipit/<airship component>-<distributive flavour>[-<version>]``; e.g. ``airshipit/armada-opensuse`` (based on recommendation from `quay.io` technical support).
Opinion 1: I think this ended up with using tags because otherwise the overhead of supporting a new distribution base or version is high (create a new quay.io docker registry). So it would be 'airshipit/drydock:ubuntu-latest' or 'airshipit/drydock:ubuntu-<commit>'. I think to maintain that backwards compatibility we can say here that if no distribution base is in the tag, it refers to an Ubuntu based image.
Opinion 2: I agree (to use tags), although the general naming scheme that I've seen in the majority of other docker repositories is: <project version #>-<distribution flavor>-<distribution flavor specifics>. So for our case that would end up being airshipit/armada:latest-ubuntu-1604 or airshipit/armada:latest-xenial
Opinion 3: IMHO Ubuntu images should have the distro in its image name so it is clear and avoid any confusion when we start have suse, centos images etc.
Opinion 4: Should we also mandate that Ubuntu includes it (distro in image name), even if it is default? Just for consistency and transparency (otherwise, looking at the Quay website, you cannot be sure which distro was used).
Opinion 5: Creation of another image repository is a one time effort; usage of separate image repositories for different base images is a recommendation from Quay.io tech.support; usage of separate image repositories for different base images allows to easily distinguish between images when trying to `docker pull ...` image without specifying a tag (assuming :latest)
Question: would we use ``airshipit/<airship component>-<distributive flavour>[-<version>]:<git tag>`` or ``airshipit/<airship component>:<distributive flavour>[-<version>]-<git tag>``?
[0] https://airship-specs.readthedocs.io/en/latest/specs/approved/airship_multi_... [1] https://storyboard.openstack.org/#!/story/2003699 [2] https://review.openstack.org/#/q/topic:airship_suse [3] https://review.openstack.org/#/c/643106/
Thank you.
Best regards, -- Roman Gorshunov
On Wed, Mar 20, 2019, at 23:36, Roman Gorshunov wrote:
Hello everyone,
We have had a few discussions previously and now have an approved spec [0] and a story [1] (many thanks to James Gu) which will help us to make Airship work with (on) various Linux distributives.
One of the first steps towards implementation of the above mentioned specification is an in-progress effort to support OpenSUSE as a base image for Airship components containers. This has started as a set of patches under `airship_suse` Gerrit topic [2] (many thanks to Arun Kant).
During the work on this patches, it has become clear that we would need to formalize the way we would build and publish images which are based on different distributives. To help with that I have created a PS [3] to set some rules on image builds & publishing, and left it for a discussion.
Discussion [3] has shown, that we have controversial opinions on implementation details. On a latest IRC meeting we have had I've volunteered to move the discussion onto the Airship community discussions mailing list (this one). This has been done:
- to reach wider audience, collect more opinions and reasoning both
in ML and in PS,
- to collectively come to the conclusion and agreement on
implementation details,
- to reflect decision in a PS [3] and get it merged to the specification [0],
- and then use specification [0] as a guidance for implementation
([2] and others in the future)
The topic and opinions are the following:
Topic Statement: Non-Ubuntu container images repository naming convention is to add a dash separator, following with a distributive flavour, optionally specifying version after dash: ``airshipit/<airship component>-<distributive flavour>[-<version>]``; e.g. ``airshipit/armada-opensuse`` (based on recommendation from `quay.io` technical support).
Opinion 1: I think this ended up with using tags because otherwise the overhead of supporting a new distribution base or version is high (create a new quay.io docker registry). So it would be 'airshipit/drydock:ubuntu-latest' or 'airshipit/drydock:ubuntu-<commit>'. I think to maintain that backwards compatibility we can say here that if no distribution base is in the tag, it refers to an Ubuntu based image.
Opinion 2: I agree (to use tags), although the general naming scheme that I've seen in the majority of other docker repositories is: <project version #>-<distribution flavor>-<distribution flavor specifics>. So for our case that would end up being airshipit/armada:latest-ubuntu-1604 or airshipit/armada:latest-xenial
Opinion 3: IMHO Ubuntu images should have the distro in its image name so it is clear and avoid any confusion when we start have suse, centos images etc.
Opinion 4: Should we also mandate that Ubuntu includes it (distro in image name), even if it is default? Just for consistency and transparency (otherwise, looking at the Quay website, you cannot be sure which distro was used).
Opinion 5: Creation of another image repository is a one time effort; usage of separate image repositories for different base images is a recommendation from Quay.io tech.support; usage of separate image repositories for different base images allows to easily distinguish between images when trying to `docker pull ...` image without specifying a tag (assuming :latest)
Question: would we use ``airshipit/<airship component>-<distributive flavour>[-<version>]:<git tag>`` or ``airshipit/<airship component>:<distributive flavour>[-<version>]-<git tag>``?
[0] https://airship-specs.readthedocs.io/en/latest/specs/approved/airship_multi_... [1] https://storyboard.openstack.org/#!/story/2003699 [2] https://review.openstack.org/#/q/topic:airship_suse [3] https://review.openstack.org/#/c/643106/
Thank you.
Best regards, -- Roman Gorshunov
Airship-discuss mailing list Airship-discuss@lists.airshipit.org http://lists.airshipit.org/cgi-bin/mailman/listinfo/airship-discuss
In OSH, we (I should say Pete) have decided to use <version>-<os>. Which makes it latest-opensuse_15 , latest-ubuntu_xenial (for non openstack images), master-ubuntu_xenial, master-opensuse_15, rocky-opensuse_15, etc.
Those are always updated images. Frozen images can be tagged when necessary. Just change the 'version' with tag or sha. We can also have labels to give extra info.
I would prefer if we used the same convention.
For the image building process, I suppose it's better if you have it directly in your repo, and reuse as much as possible what's out there. For example, reusing openstack-infra Zuul roles. OSH just builds in a single repo because we don't have the opportunity to build next to the source code.
Regards, Jean-Philippe Evrard (evrardjp)
Roman,
Thanks for bringing this to the ML.
Ubuntu images should have the distro in its image name
so it is clear and avoid any confusion when we start have suse, centos images etc.
+1 to this. It also drives consistency.
Creation of another image repository is a one time effort;
usage of separate image repositories for different base images is a recommendation from Quay.io tech.support; usage of separate image repositories for different base images allows to easily distinguish between images when trying to `docker pull ...` image without specifying a tag (assuming :latest)
If we create an additional repository, could it make multi-OS integration in scripts and tooling (e.g. Airskiff) more difficult? For example, if using the same image repository, you would just have to substitute ${DISTRO} when pulling docker images; however, if using an additional repository, the repository name must be substituted as well. The former seems like a cleaner approach.
would we use ``airshipit/<airship component>-<distributive
flavour>[-<version>]:<git tag>`` or ``airshipit/<airship component>:<distributive flavour>[-<version>]-<git tag>``?
``airshipit/<airship component>-<distributive flavour>[-<version>]:<git tag>`` is more readable to me, and I think it's what is used in OSH-images.
Best, Drew Walters (dwalt)
participants (3)
-
Drew Walters
-
Jean-Philippe Evrard
-
Roman Gorshunov