openstack team mailing list archive

[Joseph Suh <jsuh@xxxxxxx>]

Don,

Hmm, so the use of the instance_type_extra_specs is not for specifications purely any more... I am open to your proposed idea that if there is no operator, it will ignore the item (that is not original behavior of compute_filter, though). So, let me wait and see if there are any objections/comments on this issue from community, and if I don't hear them, I will implement my patch in that way.

Thanks,

Joseph

----
(w) 703-248-6160
(f) 703-812-3712
http://www.east.isi.edu/~jsuh

Information Sciences Institute
University of Southern California
3811 N. Fairfax Drive Suite 200
Arlington, VA, 22203, USA


----- Original Message -----
From: "Donald D Dugger" <donald.d.dugger@xxxxxxxxx>
To: "Joseph Suh" <jsuh@xxxxxxx>, "Sandy Walsh" <sandy.walsh@xxxxxxxxxxxxx>, "Vishvananda Ishaya" <vishvananda@xxxxxxxxx>
Cc: openstack@xxxxxxxxxxxxxxxxxxx, "Yunhong Jiang" <yunhong.jiang@xxxxxxxxx>
Sent: Tuesday, July 17, 2012 12:19:35 PM
Subject: RE: One question on the compute_filter

Joseph-

Basically, Vish & Sandy convinced me that the `instance_type_extra_specs' was the right place to put the trust info, rather than creating a new table.  I like the idea of expanding the idea of extra_specs to be used to store extra information.  I can easily imagine cases where someone wants to create a new, specialized filter that requires more information (the trusted filter is one example, there could be others).  Especially if we want the ability to add filters that aren't part of the `official` source tree, and therefore can’t change standard APIs, you'll need a place to store more info and the `instance_type_extra_specs' table is the obvious place.

Adding in comparison operators, especially the equality operator, would make it easy to have all the filters co-exist.

--
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
Ph: 303/443-3786