[Starlingx-discuss] [Container] Public docker registry

[Saul Wold]

On 12/5/18 9:55 AM, Penney, Don wrote:
> Having the openstack release and os as components of the tag vs the image name is consistent with loci and openstackhelm. I don't know if there are upgrades or patching considerations to keeping the same image name, but that could also be an argument.
> 
Ok, if there is an existing suggested format, I am OK with that.  Will 
this be put into Specification format for TSC approval?

Since we have some updated tag suggestion from Dean, that will affect 
the existing publishing specification also.

Sau!

> -----Original Message-----
> From: Saul Wold [mailto:sgw at linux.intel.com]
> Sent: Wednesday, December 05, 2018 12:49 PM
> To: Little, Scott; starlingx-discuss at lists.starlingx.io
> Subject: Re: [Starlingx-discuss] [Container] Public docker registry
> 
> 
> 
> 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
>>
> 
> _______________________________________________
> Starlingx-discuss mailing list
> Starlingx-discuss at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
>