Open Stack

But if there is one package out of all of the OS options, does that make true or false ? Or do we have a rule that says a 1 means that at least CentOS and Ubuntu are packaged ?

I remain to be convinced that a 0 or 1 can be achieved within the constraints that we need something which is useful for the operators rather than mathematically correct.

Let’s not forget the target audience for the Ops tags.

Tim

From: Anne Gentle [mailto:annegentle at justwriteclick.com]
Sent: 05 June 2015 20:21
To: Jesus M. Gonzalez-Barahona
Cc: openstack-operators at lists.openstack.org
Subject: Re: [Openstack-operators] [Tags] Tags Team Repo & our first tags!



On Thu, Jun 4, 2015 at 1:34 PM, Jesus M. Gonzalez-Barahona <jgb at bitergia.com<mailto:jgb at bitergia.com>> wrote:
[Disclamer: I'm not an OpenStack operator, neither an OpenStack
developer. I only have some experience in metrics, quality models, and
tags]

Given that tags have a clear binary value, and that some people have
expressed the convenience of having some more information available,
maybe the tags could be just the result of applying certain conditions
to a more complex description of a metric or set of metrics.

I definitely think we need both tags and descriptions. And what you describe below would be great!



For example, we could have the metric "Ops:Packaged", which could be a
detailed description of how the module is packaged, for example as a
JSON document:

{"complete-pkgs": 2,
 "complete-pkgs-list": [{"system": "Debian", "url": ...}, {... }]
 "wip-pkgs": 1,
 "wip-pkgs": [...],
 ...
}

And then one or more tags, based on conditions stated in that JSON. For
example, the tag "Ops:Well-Packaged" could be defined for those
"Ops:Packaged" with more than 5 in the "complete-pkgs" field, or with at
least certain systems in "complete-pkgs-list", or whatever.

But you could also define the tag "Ops:Basic-Packaged", if that is
useful, for those covering say at least Ubuntu and CentOS.

That way, an operator could just go for the tag, if that's enough for
them. But they could also look at the complete definition of the metric,
if they need more detail. My guess is that as the use of OpenStack
becomes more and more complex, people will need more and more
information to take decisions. And having metrics and tags this way
provide the best of both worlds: tags are simple, binary, while metrics
are detailed and can capture complexity (for example, the above JSON
format could be extended to have into account specific releases for
which packages are available).

Another advantage is that tags could be derived automatically from
metrics, and at least some metrics could be derived as well
automatically from factual information (such as the existence of those
packages in the corresponding repository). All of that would simplify a
lot the maintenance of tags over time.

Agreed. I'd love it if the ops team is willing to encode as much as they can and keep iterating over time.

This tagging definition work won't be done for a while but we should keep poking at the problem with real data. I'm happy to have the ops team keep working on it and then come back to the TC with their list, similar to how the API Working Group is working separately from the TC.

Anne


Saludos,

        Jesus.

On Thu, 2015-06-04 at 10:49 -0400, Jonathan Proulx wrote:
> Been sort of chewing on the various opinions expressed ...
> clearly this decision needs to be one of the first things to come
> out of  the ops-tags team
>
> I think we could do most of what we need with binary tags if those
> were hierarchical ie this tag means those other five are also applied,
> but multiplies the number of tags by a lot and I think multiplies
> complexity especially since many (perhaps most) of our tags will
> require human judgement.
>
> Having a common schema for ops tags may allow us to retain the
> richness of the content while not unnecessarily complicating their use
> for example
>
> <tagname>:
>   value: <string>
>   bug_list: [<maybe empty url_list>]
>   description: <maybe empty string>
>   exceptions: <maybe empty string>
>
> Of these I'm not sure description and exceptions are needed but I'm
> pretty sure value and bug list are, and once we have a data structure
> beyond binary or key-value adding those two doesn't raise complexity
> significantly and does add some value.
>
> Once we do set a precedent for either binary tags or rich tags I have a
> feeling it will stick hard, especially if we choose binary.
>
> If we really find we can define all the tags we want with just a true or false
> value then there's no point in complicating things and the additional info could
> likely be provided in a wiki page or something as a concordance to the tags
> rather than in the tag itself.
>
> So I'd like to challenge those of us currently advocating structured rather
> than binary tags to come up with tag examples we feel are necessary and
> nonbinary.
>
> The install-guide tag likely could be binary, though enriching 'false'
> with links to less official or work in progress documentation could be
> valuable a web search could hopefully get you that, exceptions might
> be useful if a distro does something that breaks an install guide for
> that one case and if there is an exception a bug pointer would be
> ideal, IMO.
>
> The packaged tag I think is a stronger case for structured content.
> Imagine we break it down to the obvious packaged-deb and packaged-rpm
> there's still much complexity back there and I think we'd need
> exceptions.
>
> -Jon
>
> On Wed, Jun 3, 2015 at 1:29 PM, Richard Raseley <richard at raseley.com<mailto:richard at raseley.com>> wrote:
> > Thierry Carrez wrote:
> >>
> >> It's visible in the tag description. Each tag is backed by a precise
> >> definition that explains what the tag means.
> >>
> >> Tags as designed are labels, not metrics. We define what "well-packaged"
> >> means, and then apply that label to projects that fit the bill.
> >>
> >> If we mix the messaging by making tags be both labels and metrics, then
> >> it will be extra-hard to make a project navigation website to expose both.
> >>
> >> That said, the Ops tags WG is pretty much on the same line -- the
> >> discussion we had in Vancouver was that we should define subjectively
> >> what "well-packaged" means, and than apply it objectively. Same for the
> >> other ops tags. So I think we are actually on the same line...
> >
> >
> > I just wanted to add my voice to say that, as an operator, I completely
> > agree with what both you and Jay are saying here.
> >
> > The tags do offer value (I've come around since the mid-cycle operators
> > meet-up), and I think we should remain consistent in terms of defining the
> > model around them as a binary indication of compliance with a particular set
> > of criteria.
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
--
Bitergia: http://bitergia.com
/me at Twitter: https://twitter.com/jgbarah


_______________________________________________
OpenStack-operators mailing list
OpenStack-operators at lists.openstack.org<mailto:OpenStack-operators at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



--
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com<http://www.justwriteclick.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150605/5112659b/attachment.html>