Re: [Openstack] 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.ji...@intel.com To: j...@isi.edu Cc: Donald D Dugger donald.d.dug...@intel.com, openstack@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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] One question on the compute_filter
-Original Message- From: Jim Fehlig [mailto:jfeh...@suse.com] Sent: Tuesday, July 17, 2012 11:37 AM To: Jiang, Yunhong Cc: j...@isi.edu; openstack@lists.launchpad.net Subject: Re: [Openstack] One question on the compute_filter Jiang, Yunhong wrote: 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. I have been working on a patch [1] that allows the ComputeFilter to filter on (architecture, hypervisor_type, vm_mode) triplet as specified in the *instance properties*. In the blueprint you mention, I see cpu_type=itanium as an example of a key/value in the extra_specs of instance types. Are architecture, preferred hypervisor, and vm_mode (PV vs HVM) properties of the image (which are used to populate the instance_properties) or properties of a flavor (used to populate instance_type)? IMO, they are properties of an image. Jim, thanks for your input very much. I agree with you that architecture is better through instance_property. For vm_mode or hypervisor_type, I'm not sure what will happen if an image can be used in both Xen/KVM environment (I'm not familiar with the image code yet). But I agree that at least it's better to be in instance_property than in flavor. The blueprint in http://wiki.openstack.org/HeterogeneousInstanceTypes gives some example of extra_specs, seems it includes cpu_info, cpu_arch etc. Although I'm not sure if this blueprint is valid still. What are the other commonly used extra_specs that are being checked by the ComputeFilter? Are they properties of an image or a flavor? Seems currently the ComputeFilter check extra_spec according to the host capability. And the TrustedFilter check extra_spec for trusted host. --jyh Perhaps the checks for extra_specs can be removed from the ComputeFilter entirely and done by other filters as you mention. Regards, Jim [1] https://lists.launchpad.net/openstack/msg14121.html ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] One question on the compute_filter
-Original Message- From: Joseph Suh [mailto:j...@isi.edu] Sent: Tuesday, July 17, 2012 9:38 PM To: Jiang, Yunhong Cc: Dugger, Donald D; openstack@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. Joseph, thanks for clarification. 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, The issue here is, if I create such another filter, then it possibly can't co-exist with compute filter :( --jyh 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.ji...@intel.com To: j...@isi.edu Cc: Donald D Dugger donald.d.dug...@intel.com, openstack@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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] 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:j...@isi.edu] Sent: Tuesday, July 17, 2012 7:38 AM To: Jiang, Yunhong Cc: Dugger, Donald D; openstack@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.ji...@intel.com To: j...@isi.edu Cc: Donald D Dugger donald.d.dug...@intel.com, openstack@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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] One question on the compute_filter
Yunhong, I understand your concern. It has a different purpose than the compute_filter, so it has its own merit and can co-exist. The question is how much the demand is... 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: Yunhong Jiang yunhong.ji...@intel.com To: Joseph Suh j...@isi.edu Cc: Donald D Dugger donald.d.dug...@intel.com, openstack@lists.launchpad.net Sent: Tuesday, July 17, 2012 11:39:54 AM Subject: RE: One question on the compute_filter -Original Message- From: Joseph Suh [mailto:j...@isi.edu] Sent: Tuesday, July 17, 2012 9:38 PM To: Jiang, Yunhong Cc: Dugger, Donald D; openstack@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. Joseph, thanks for clarification. 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, The issue here is, if I create such another filter, then it possibly can't co-exist with compute filter :( --jyh 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] 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.dug...@intel.com To: Joseph Suh j...@isi.edu, Yunhong Jiang yunhong.ji...@intel.com Cc: openstack@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:j...@isi.edu] Sent: Tuesday, July 17, 2012 7:38 AM To: Jiang, Yunhong Cc: Dugger, Donald D; openstack@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.ji...@intel.com To: j...@isi.edu Cc: Donald D Dugger donald.d.dug...@intel.com, openstack@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
Re: [Openstack] 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 -Original Message- From: Joseph Suh [mailto:j...@isi.edu] Sent: Tuesday, July 17, 2012 10:10 AM To: Dugger, Donald D Cc: openstack@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.dug...@intel.com To: Joseph Suh j...@isi.edu, Yunhong Jiang yunhong.ji...@intel.com Cc: openstack@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:j...@isi.edu] Sent: Tuesday, July 17, 2012 7:38 AM To: Jiang, Yunhong Cc: Dugger, Donald D; openstack@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.ji...@intel.com To: j...@isi.edu Cc: Donald D Dugger donald.d.dug...@intel.com, openstack@lists.launchpad.net Sent: Monday, July 16, 2012 10:00:44 AM Subject: One question on the compute_filter Hi, Joseph I’m
Re: [Openstack] One question on the compute_filter
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.dug...@intel.com To: Joseph Suh j...@isi.edu, Sandy Walsh sandy.wa...@rackspace.com, Vishvananda Ishaya vishvana...@gmail.com Cc: openstack@lists.launchpad.net, Yunhong Jiang yunhong.ji...@intel.com 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] One question on the compute_filter
Joseph- Tnx, we couldn't ask for more. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 -Original Message- From: Joseph Suh [mailto:j...@isi.edu] Sent: Tuesday, July 17, 2012 10:49 AM To: Dugger, Donald D Cc: openstack@lists.launchpad.net; Jiang, Yunhong; Sandy Walsh; Vishvananda Ishaya Subject: Re: One question on the compute_filter 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.dug...@intel.com To: Joseph Suh j...@isi.edu, Sandy Walsh sandy.wa...@rackspace.com, Vishvananda Ishaya vishvana...@gmail.com Cc: openstack@lists.launchpad.net, Yunhong Jiang yunhong.ji...@intel.com 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] One question on the compute_filter
Jiang, Yunhong wrote: 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. I have been working on a patch [1] that allows the ComputeFilter to filter on (architecture, hypervisor_type, vm_mode) triplet as specified in the *instance properties*. In the blueprint you mention, I see cpu_type=itanium as an example of a key/value in the extra_specs of instance types. Are architecture, preferred hypervisor, and vm_mode (PV vs HVM) properties of the image (which are used to populate the instance_properties) or properties of a flavor (used to populate instance_type)? IMO, they are properties of an image. What are the other commonly used extra_specs that are being checked by the ComputeFilter? Are they properties of an image or a flavor? Perhaps the checks for extra_specs can be removed from the ComputeFilter entirely and done by other filters as you mention. Regards, Jim [1] https://lists.launchpad.net/openstack/msg14121.html ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
