Open Stack

Excerpts from Jay Pipes' <jaypipes at gmail.com> message on 23/04/2014
01:43:42:

> On Tue, 2014-04-22 at 13:14 +0200, Thomas Spatzier wrote:
> > <snip>
> > >  * Identify key/value pairs that are relied on by all of Nova to be a
> > > specific key and value combination, and make these things actual real
> > > attributes on some object model -- since that is a much greater guard
> > > for the schema of an object and enables greater performance by
allowing
> > > both type safety of the underlying data and removes the need to
search
> > > by both a key and a value.
> >
> > Makes a lot of sense to me. So are you suggesting to have a set of
> > well-defined property names per resource but still store them in the
> > properties name-value map? Or would you rather make those part of the
> > resource schema?
>
> I'd rather have the common ones in the resource schema itself, since
> that is, IMHO, better practice for enforcing consistency and type
> safety.

+1, that's what I would prefer as well, but I wanted to make sure you mean
the same.

>
> > BTW, here is a use case in the context of which we have been thinking
about
> > that topic: we opened a BP for allowing constraint based selection of
> > images for Heat templates, i.e. instead of saying something like (using
> > pseudo template language)
> >
> > "image ID must be in [fedora-19-x86_64, fedora-20-x86_64]"
> >
> > say something like
> >
> > "architecture must be x86_64, distro must be fedora, version must be
> > between 19 and 20"
> >
> > (see also [1]).
> >
> > This of course would require the existence of well-defined properties
in
> > glance so an image selection query in Heat can work.
>
> Zactly :)
>
> > As long as properties are "just" custom properties, we would require a
lot
> > of discipline from every to maintain properties correctly.
>
> Yep, and you'd need to keep in sync with the code in Nova that currently
> maintains these properties. :)
>
> Best,
> -jay
>
> >  And the
> > implementation in Heat could be kind of tolerant, i.e. give it a try,
and
> > if the query fails just fail the stack creation. But if this is likely
to
> > happen in 90% of all environments, the usefulness is questionable.
> >
> > Here is a link to the BP I mentioned:
> > [1]
> > https://blueprints.launchpad.net/heat/+spec/constraint-based-
> flavors-and-images
> >
> > Regards,
> > Thomas