[Openstack-operators] [ops][tags][packaging] ops:packaging tag - a little common sense, please

Thierry Carrez thierry at openstack.org
Thu Jun 11 08:08:11 UTC 2015

Jay Pipes wrote:
> [...]
> = Packaging tags should be release-specific, or they will be wrong =
> For these packaging tags, the release must be part of the tag itself,
> otherwise the information it denotes would be indeterminate.
> As an example, suppose you have a tag that looks like this:
>  ops:packaged:centos:good
> And in the tag definition you say that the tag is applied to projects
> that have CentOS RPM packages available "within the last 6 months".
> Well, as you all know, packages are published for a *particular release
> of OpenStack*. So, if Nova is tagged with ops:packaged:centos:good in,
> say, August 2015, the tag would ostensibly be saying that packages exist
> for Nova in Kilo. However, once November rolls around, and packages for
> Liberty don't (yet) exist, are you going to remove this
> "ops:packaged:centos:good" tag from Nova or (worse) change it to
> "ops:pacakged:centos:no"?
> Instead, have the tag be specific to a release of OpenStack:
> packaged:centos:kilo

There is a provision in the tag framework for (secondary) attributes. So
far we only used it to track the "since when" information on the
"integrated-release" legacy tag.

If packaging basically carries over, the only interesting bit of
information is "what is the first release cycle the packaging appeared
in", so you could actually have:

- repo: openstack/nova
    - name: packaged:centos
      since: diablo

I think it's easier and simpler to maintain.

Thierry Carrez (ttx)

More information about the OpenStack-operators mailing list