Excerpts from Jay Pipes' <jaypi...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev