Open Stack

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


-----Original Message-----
From: Joseph Suh [mailto:jsuh at isi.edu] 
Sent: Tuesday, July 17, 2012 10:10 AM
To: Dugger, Donald D
Cc: openstack at lists.launchpad.net; Jiang, Yunhong
Subject: Re: One question on the compute_filter

Don,

That's an interesting idea, but I am having a difficulty in understanding why you want to store extra information (not spec) in instance_type_extra_specs. If you need to keep some extra information, using or creating another flag or field in database might be a better place for that? The intention of having instance_type_extra_specs is to extend the instance_types table to accommodate extra specs that cannot be enumerated at the time of coding, and it would be best if we have the same behavior as instance_types in my opinion.

Thanks,

Joseph

----
(w) 703-248-6160
(c) 571-340-2434
(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 at intel.com>
To: "Joseph Suh" <jsuh at isi.edu>, "Yunhong Jiang" <yunhong.jiang at intel.com>
Cc: openstack at lists.launchpad.net
Sent: Tuesday, July 17, 2012 11:47:25 AM
Subject: RE: One question on the compute_filter

Joeseph-

My concern is that this means that the compute filter consumes `every` entry in the `extra_specs' table.  I can imagine scenarios where other filters would want to put data in `extra_specs' that is not intended for the compute filter.  In fact, we do that today with the trusted filter that was recently added where there is a `trusted_host' key that is added to the `extra_specs' table.

I really like the idea of adding operators to the compute filter.  This would mean that if you truly wanted the compute filter to check for the presence of capability you just explicitly specify the equality operator.  Any `extra_specs' keys that don't have an operator would just be ignored, giving the administrator maximum flexibility in specifying capabilities.

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


-----Original Message-----
From: Joseph Suh [mailto:jsuh at isi.edu] 
Sent: Tuesday, July 17, 2012 7:38 AM
To: Jiang, Yunhong
Cc: Dugger, Donald D; openstack at lists.launchpad.net
Subject: Re: One question on the compute_filter

Yunhong,

Thanks for your interest in our patch. The original purpose of the instance_type_extra_specs is providing ability to specify any specs that cannot be enumerated at the nova coding time such as hardware-specific requirements (like gpu) or any features in the future system (like python version 10). System administrator will populate necessary items at the time of deployment as he/she wants. Current compute_filter is a relatively simple code that compares the items in the instance_type_extra_specs with those in capability. In our patch, we want to add more operators, not changing the basic behavior.

The idea behind the compute_filter is that if items are specified in instance_type_extra_specs, the filter makes it sure that all the requested items are in the capability of the provisioned hosts. 

So, in your approach, if you already know items that is required such as xpu_arch and want to ignore other items in the instance_type_extra_spec, one way might be to create another filter that checks only those known items. But, then, if there is a need to check another item or ignore an item in the future, the filter code needs to be modified. In our approach, it can be simply added/deleted in database by system administrator.

Thanks,

Joseph

----
(w) 703-248-6160
(c) 571-340-2434
(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: "Yunhong Jiang" <yunhong.jiang at intel.com>
To: jsuh at isi.edu
Cc: "Donald D Dugger" <donald.d.dugger at intel.com>, openstack at lists.launchpad.net
Sent: Monday, July 16, 2012 10:00:44 AM
Subject: One question on the compute_filter




Hi, Joseph 

I’m working on the patch for blueprints https://blueprints.launchpad.net/nova/+spec/update-flavor-key-value , to add/delete the extra_specs for flavor through nova-manage. I’m still setting up my environment to push the patch. 



However, when I was testing my patch, I noticed that compute_filter assume it will handle all of the “extra_specs”. If it can’t find corresponding key in the capabilities, it will fail to pass the host. IMHO, this is a bit overkill. For example, currently the trusted_filter.py will use the extra_specs to check if trusted_host is required, that means compute filter and trusted filter can’t be used at the same time. 

I think compute filter should define explicitly all keys that it takes care, like cpu_info, cpu_arch, xpu_arch, and only check the corresponding extra_specs key/value pair? After all, extra_specs is not compute_extra_specs? 

I noticed the patch in https://review.openstack.org/#/c/8089/ , but seems this patch will not fix this issue still. 



Any idea or suggestion? I’m glad to create patch if any conclusion on this issue. 



Thanks 

--jyh