An alternate schema, and the one in current use, places the os and openstack-release under the tag section. 

This has the advantage of lower administrative overhead.  It takes 'admin' powers to create a new <image>, whereas anyone with write permissions can create a new <tag>.

Lets call this version 2.


Image naming schema

<image-name>=<org>/<image>:<tag>
<org>=starlingx
<image>=stx-<component>

<tag>=<git-tag-or-branch>-<os>-<openstack-release>[-<qualifier>]

<os>=centos | ubuntu | clear-linux

<openstack-release>=pike | queens | rocky ...
<component>=aodh | ceilometer| cinder | glance | gnocchi | heat | horizon | ironic | keystone | libvirt | magnum | murano | neutron | nova-api-proxy | nova | panko ...

<qualifier>=<timestamp> | latest | stable

<git-tag-or-branch>=dev | r2018.10 | r2018.10.0 | ...

Note: 'dev' replaces 'master'


On 18-12-04 01:29 PM, Scott Little wrote:

Here is my proposal for the StarlingX docker repository.

Docker repository location

- hub.docker.com, as a public set of repositories under the organization 'starlingx'

Build frequency

- On demand for release/milestone branches

- Will probably start with daily for master branch.  Perhaps when things stabilize we'll reduce build frequency, or even use commit driven builds.

Retention policy

- Perhaps two weeks for master branch builds?  but always one 'stable' build (see below)

- Will start with daily for master branch.  Perhaps when things stabilize we'll reduce build frequency, or even use commit driven builds.

Image naming schema

<image-name>=<org>/<image>:<tag>
<org>=starlingx
<image>=stx-<os>-<openstack-release>-<component>

<tag>=<git-tag> | <git-branch>[-<qualifier>]

<os>=centos | ubuntu | clear-linux

<openstack-release>=pike | queens | rocky ...
<component>=aodh | ceilometer| cinder | glance | gnocchi | heat | horizon | ironic | keystone | libvirt | magnum | murano | neutron | nova-api-proxy | nova | panko ...

<qualifier>=<timestamp> | latest | stable

<git-tag-or-branch>=master | r2018.10 | r2018.10.0 | ...

Note: we can't have the '/' or ':' character in a branch name. So r/2018.10 would have to be shortened to 'r2018.10'.
However i think it's better to use the tag to allow for rebuilds of a release '2018.10.0'. My only concern here is that our current git tagging convention doesn't distinguish release from milestone.  I would prefer a 'r' or 'm' prefix on our git tags.

Note: the 'latest' or 'stable' qualifiers would be aliases to the timestamped image.  'Stable' might be over selling it on master branch... perhaps some other term... 'tested', 'usable'?


e.g.

starlingx/stx-centos-pike-nova:master-20181201
starlingx/stx-centos-pike-nova:master-20181202
starlingx/stx-centos-pike-nova:master-20181203
starlingx/stx-centos-pike-nova:master-latest   -> master-20181203
starlingx/stx-centos-pike-nova:master-stable   -> master-20181201

starlingx/stx-centos-pike-nova:r2018.10.0
starlingx/stx-centos-pike-nova:r2018.10.1
starlingx/stx-centos-pike-nova:r2018.10-latest  -> r2018.10.1

Comments?

Scott
 


_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss@lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss