[Starlingx-discuss] [Container] Public docker registry

Saul Wold sgw at linux.intel.com
Wed Dec 5 17:48:38 UTC 2018



On 12/4/18 1:26 PM, Scott Little wrote:
> 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.
>
Seems like a good plan with one suggestion below.

> *
> *
> 
> *Image naming schema*
> 
> <image-name>=<org>/<image>:<tag>
> 
> <org>=starlingx
> 
> <image>=stx-<component>
> 
> <tag>=<git-tag-or-branch>-<os>-<openstack-release>[-<qualifier>]
> 
I am wondering if it would make more sense to keep the 
<openstack-release> item in the <image> part.  It's going to be more 
stable over time than the other parts.

my 2 cents

Sau!

> <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 at lists.starlingx.io
>> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 
> 
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
> 



More information about the Starlingx-discuss mailing list