[Openstack-operators] [Tags] Tags Team Repo & our first tags!
Jesus M. Gonzalez-Barahona
jgb at bitergia.com
Sun Jun 7 08:22:53 UTC 2015
On Fri, 2015-06-05 at 18:34 +0000, Tim Bell wrote:
>
>
> 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 ?
Tags would be defined based on the agreed conditions over metadata. For
example, a tag "is_packaged" could be defined so that it is True if the
module is packaged for at least one distro, while another tag
"is_packaged_all" could be defined so that it is True for all "supported
distros", if at some point that concept exists. Or "is_packaged_centos"
could be True if it is packaged for CentOS, at least.
That would depend on which tags operators consider useful, and on
whether there is some agreement on them. To me, tags such as
"is_packaged" have some value, since that means that at least I can
deploy on some distro, and maybe I can produce the packaging stuff for
some other distro easier, if I need. Or "is_packaged_centos", which
means that if I'm deploying in CentOS, I'm done. But well, I'm not an
operator.
> 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.
That depends only on whether it is possible to find boolean conditions
that lead to useful tags for operators. I guess some of those have
already been mentioned in this thread, but of course that's something to
be discussed. In any case, my impression is that if we have both
metadata and tags based on metadata, anyone can use what is more useful
for them.
Maybe we could go over the different domains and tags proposed, and
discuss on a case by case basis...
Saludos,
Jesus.
>
> 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> 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
>
>
> _______________________________________________
> 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
More information about the OpenStack-operators
mailing list