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