Open Stack

Cross-posting to -operators and -dev because this involves *packagers* 
of OpenStack, as well as operators who use those packages.

Hello Operators,

First, let me start out by saying if you were offended by my snarky 
comments at yesterday's TC meeting [1] regarding the direction of the 
Ops Tags Team, I apologize. Sometimes I am snarky and/or moody, 
especially when I feel strongly about something, as is the case here. 
Please accept my apologies. Let's move on.

= tl;dr =

* The proposed things are not tags
* Operators should not be curating packaging tags (packagers should)
* Tags should not have a "value" component
* Packaging tags should be release-specific, or they will be wrong

= The details =

OK, that said, here are the issues I have with the proposed 
ops:packaging tags [2].

= The proposed things are not "tags" =

The things being proposed by the Ops Tags Team are in fact not "tags", 
which are simple strings of binary information that have a well-defined 
and singular meaning.

What the Ops Tags Team has proposed is structured, schema-full data 
objects. There is nothing wrong with having a structured object for 
purposes of generating useful information. But please don't call these 
things "tags", because they aren't.

Before I move on to other issues, I'd like to point out that the more 
you go down the route of adding more and more attributes, most of which 
would be optional, to these structured documents, the more you will run 
into a problem of having stale and misleading data contained in these 
JSON files. And that will lead to a worse user experience for operators 
than the current wiki, which, like all wikis, is notoriously out-of-date 
in many places.

A tag should mean one thing, and one thing only, to encourage clarity. 
The definition of the tag should be decisive regarding why a particular 
project has been tagged with that tag.

= Operators should not be curating packaging tags =

*Packagers* should be curating tags that correspond to whether or not 
packages exist for particular projects in OpenStack. Operators consume 
these packages, for sure, but the packagers in the upstream operating 
system communities are the ones that know the most accurate information 
about the state of packaging for a particular project and a particular 
release.

I strongly believe that these ops:packaged tags should really just be 
tags in the openstack/governance repository (i.e. regular TC tags) and 
be curated by the packaging community, which means they would not have 
the "ops:" prefix on them.

= Remove "value" component from the "tag" =

The current proposal for both ops:packaged and ops:production-use [3] 
tag definitions include a "value" component. For example, the 
ops:packaged tags must include one of the following "values":

  - good
  - beginning
  - warning
  - no

With each of the above values attempting to indicate to the audience 
that the packages for a particular project are in varying states of 
repair and "bug-freeness". There are a number of problems with including 
this "value" in the tag:

1) This value judgement about the packaging quality is ripe for getting 
out-of-date VERY quickly. Who is going to continually update the value 
parts for the different projects? Things change very quickly in 
packaging-land. Bugs are fixed, new packages built and published. Who in 
the ops community is going to track this? Please see point above about 
"Operators should not be curating packaging tags".

2) All software, including packages, has bugs. This is something that 
the Ops community just needs to accept and get over. Quabbling with each 
other about what constitutes a "major" bug in packaging and how many 
"major" bugs bugs constitute a "warning" value is less than useful to 
the audience here. Instead, the ops community should focus on providing 
useful documentation and links to the audience, in the form of long-form 
release notes or opinions about packages and documentation on the 
OpenStack wiki.

= 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

= In summary =

In short, I would love it if the Ops Tags team would stick with binary 
tag definitions -- a tag should mean one thing and one thing only.

I don't believe the Ops Tags team should be curating the packaging tags 
-- the packaging community should do that, and do that under the main 
openstack/governance repository.

Packagers, I would love it if you would curate a set of tags that looks 
kind of like this:

  - packaged:centos:kilo
  - packaged:ubuntu:liberty
  - packaged:sles:juno

I will be proposing the above tag definition to the openstack/governance 
repository this week.

Thanks for listening,
-jay

[1] 
http://eavesdrop.openstack.org/irclogs/%23openstack-meeting/%23openstack-meeting.2015-06-09.log.html#t2015-06-09T20:18:00
[2] https://review.openstack.org/#/c/186633
[3] https://review.openstack.org/#/c/189168