[Starlingx-discuss] [Container] Public docker registry
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
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
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
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. -----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
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
On Tue, Dec 4, 2018 at 12:31 PM Scott Little <scott.little@windriver.com> wrote:
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.
For other reasons (mostly to do with the change to consume upstream OpenStack from master) I am thinking we should adjust how we implement milestones. The TSC has already talked about adjusting our release schedule, and thus the milestone schedule, to align closer to the OpenStack cadence (The release team is going to dive in to this in more detail so final proposal TBD). If we do this the following are the changes I am anticipating: * do not branch milestones, just tag master * follow the OpenStack process of appending a suffix to the milestone tag to identify which milestone (ie 'b1' for milestone 1, etc: NNNNb1) The major problem with this, and why I didn't adopt it from the start, is that we are using date-based release tags rather than semantic versioning (semver, the X.Y.Z we all know and love) so the value of the next release tag can be anticipated but not certain. For example, until a short time ago we had anticipated the next release to be 2018.03, now it is more likely to be 2018.05. That makes it hard to tag a milestone in January and have it all make sense. dt -- Dean Troyer dtroyer@gmail.com
Personally I don't like embedding a predicted release date in the milestone. As we've seen they are subject to change. If the milestone tag is to live on master branch, I'd prefer using the date the tag is made. So the 'b#' suffix would be unique to the milestone builds? I could live with that. My main ask is that there be a machine parsable way to distinguish a milestone tag from a release tag. The easiest to parse would be a prefix. <release-prefix><year><month><build-number> <milestone-prefix><year><month><day-or-build-number-whatever-you-like> Want to see all release tags ? git tag | grep '^<release-prefix>' Want latest milestone ? git tag | grep '^<milestone-prefix>' | sort --unique | tail -n 1 On 18-12-04 05:54 PM, Dean Troyer wrote:
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. For other reasons (mostly to do with the change to consume upstream OpenStack from master) I am thinking we should adjust how we implement milestones. The TSC has already talked about adjusting our release schedule, and thus the milestone schedule, to align closer to the OpenStack cadence (The release team is going to dive in to this in more detail so final proposal TBD). If we do this the following are
On Tue, Dec 4, 2018 at 12:31 PM Scott Little <scott.little@windriver.com> wrote: the changes I am anticipating:
* do not branch milestones, just tag master * follow the OpenStack process of appending a suffix to the milestone tag to identify which milestone (ie 'b1' for milestone 1, etc: NNNNb1)
The major problem with this, and why I didn't adopt it from the start, is that we are using date-based release tags rather than semantic versioning (semver, the X.Y.Z we all know and love) so the value of the next release tag can be anticipated but not certain. For example, until a short time ago we had anticipated the next release to be 2018.03, now it is more likely to be 2018.05. That makes it hard to tag a milestone in January and have it all make sense.
dt
participants (4)
-
Dean Troyer
-
Penney, Don
-
Saul Wold
-
Scott Little