Open Stack

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.

> 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
> 
> >
> > Best,
> > -jay
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev