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@linux.intel.com] Sent: Wednesday, December 05, 2018 12:49 PM To: Little, Scott; starlingx-discuss@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@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss