Open Stack

On Thu, Jun 4, 2015 at 1:34 PM, Jesus M. Gonzalez-Barahona <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>
> 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
> > >
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > 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
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



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