Image naming standard

[PhillypHenning]

Moving a conversation started in Slack into a discussion tab

[PhillypHenning]

@mickmcgrath13

[mickmcgrath13]

My vote is either

1. forgo :latest (and v2.0.0) in favor of :latest-core and :latest-kitchensink (and v2.0.0-core and v2.0.0-kitchensink)
2. or :latest (and v2.0.0) is core, and :latest-* (and v2.0.0-*) is core + other stuff with a bold note on the non-suffixed images that say "THIS IS CORE! IT HAS NO PLUGINS! To use images that have plugins pre-built, use these "

[PhillypHenning]

I'm not directly opposed to your last suggestion but I did have something I wanted to point out;

Base

1. the lowest part or edge of something, especially the part on which it rests or is supported.
2. a conceptual structure or entity on which something draws or depends.

I personally believe that the core should be renamed to something that represents foundation from an architecture perspective.

Lobby (KitchenSink)

1. a room providing a space out of which one or more other rooms or corridors lead, typically one near the entrance of a public building.

Though I'm not advocating for this naming, I do like the idea of breaking this down like a building. The lobby therefor should be the first thing a user sees and has access to. The lobby is large and contains rooms that may or may not be used by the user.

Rooms (Plugins)

1. space that can be occupied or where something can be done, especially viewed in terms of whether there is enough.
2. a part or division of a building enclosed by walls, floor, and ceiling.

Finally, rooms would then fit as the individual plugins. Based off the same layout as the lobby, however, likely more constrained in the "space" (or in our case tools) available.

[ConnorGraham]

Consider how the official node docker image (and others) do their tagging:

${VERSION}-${SUBSET}${SUBSET_VERSION}

Where SUBSET and SUBSET_VERSION are optional. This is best illustrated with some examples:

• node:18-alpine3.15
• node:16-buster
• node:lts-gallium
• node:current-alpine3.16

With this knowledge, I think we should tag in a similar way:

${BTIOPS_VERSION}-${PLUGIN_OR_PLUGIN_AGGREGATE}${PLUGIN_OR_PLUGIN_AGGREGATE_VERSION}

Some examples:

• bitops:2.0.0
• bitops:2.0.0-terraform1.2
• bitops:2.0.0-kitchensink
• bitops:2.0.0-kitchensink3.1

Key points:

1. Drop the v from v2.0.0
2. core does not exist. It is implied by a tag with the absence of a PLUGIN_OR_PLUGIN_AGGREGATE section

[PhillypHenning]

By golly I think the man has done it

[ConnorGraham]

I suppose BITOPS_VERSION could also be optional. Its absence would assume latest. Akin to node:alpine3.15

[PhillypHenning]

@mickmcgrath13 what are your thoughts on this approach

[arm4b]

Good point on following the other projects in the OSS so we'll do something that more people already seen before and normally would expect, +1 dropping the v prefix 👍

[arm4b]

Perhaps in the future it's also cool to do additional Docker tagging so users can pin to the most recent major/minor versions depending on their needs: bitops:2, bitops:2.1, bitops:2.1.1, like described in this VERSIONING.md example.

But it's probably just more unnecessary work for now :)

[PhillypHenning]

https://github.com/bitovi/bitops/wiki/Image-naming#official-images

[PhillypHenning]

Chris;

• Use aws- instead of a as it is to ambiguous

[mickmcgrath13]

• a-terraform - let's do aws-terraform rather than a (see above)
• should have things like
  • aws-kitchensink <-- latest for aws
  • 2.0.0-aws-kitchensink
  • 2.0.0-aws-terraform1.2 <-- bitops v2.0.0 & tf plugin version 1.2
• 2.0.0 and latest <-- is latest for the 3 main cloud providers and tf, helm, and ansible
• base image naming: call it base

Need to decide:
Is there a better term for specifying everything instead of kitchensink. Put this in the general room.

Next steps

• decide kitchensink vs anything else (post in general)
• provide docs about our pre-built images, what they mean, and how to request a new one
• update wiki based on the above: https://github.com/bitovi/bitops/wiki/Image-naming#official-images
• update the CI pipelines

[mickmcgrath13]

naming convention based on latest discussions:

merges into branches:

• $branchname-*
• ex: main (omnibus), main-base, main-awsterraform
• ( main only for now)

releases:
$releasetag-*

• ex tag 2.0.0: 2.0.0 (omnibus), 2.0.0-base, etc
• ex tag 2.0.0-RC: 2.0.0-RC (omnibus), 2.0.0-RC-base, etc
• would also create: latest (omnibus), base

[arm4b]

The purpose of main as a tag could be a bit confusing, especially with having base.
I'd still recommend renaming it more explicitly like dev and avoiding creating branches so users won't try to rely on that, because the naming might hint at some general purpose meaning, clashing with the production images.

[arm4b]

The initial confusion I had is that on BitOps Docker Hub there's a list of so different tags:

• latest
• plugins
• plugins-base-RC
• plugins-omnibus
• plugins-aws-ansible
• plugins-base-RC-aws-ansible
• 2.0.0-aws-helm-PR
• 2.0.0-latest
• 2.0.0-base
• 2.0.0-aws-terraform-pre
• v1.0.18

The users would quickly browse the BitOps Docker Hub as a source of truth and pick the preferred official image based on the naming. This is another homepage to keep clean, consistent, and predictable with no surprises.

[PhillypHenning]

I'll have to go in and clean this up again

[mickmcgrath13]

@PhillypHenning @armab can we lock this discussion?

Is this up-to-date? https://github.com/bitovi/bitops/wiki/BitOps-Docker-Image

If not, can one of you create a ticket to close this out and formally resolve the image naming discussion?

[arm4b]

This should do it to synchronize all the previous discussions, documents, CD changes, and efforts as an official doc: #278

[arm4b]

The stabilized BitOps versioning is now part of the official docs: https://bitovi.github.io/bitops/versioning/ and includes explanation and example table with the docker image naming and tagging.
That's pretty much a crowdsourced doc, thanks everyone for the discussion! 👍