Re: [Openstack] [Nova] Instance Type Extra Specs clarifications
A bug fix patch that adds the extra specs matching against host aggregate is under review at https://review.openstack.org/#/c/11449/. Thanks, Joseph - Original Message - From: Vishvananda Ishaya vishvana...@gmail.com To: Joseph Suh j...@isi.edu Cc: Patrick Petit patrick.michel.pe...@gmail.com, openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Friday, August 24, 2012 10:10:05 PM Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications Folsom also supports setting key values for things like capabilities via host aggregates. There is a filter[1] that matches the extra specs by exact comparison just like was done for capabilities before the last patch. The new extra specs matching should be added to it. These capabilities can be set dynamically by administrators so it directly supports the use case below. [1] https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_instance_extra_specs.py On Aug 24, 2012, at 6:39 PM, Joseph Suh j...@isi.edu wrote: Patrick, That's a good point. I think the issue is already being discussed at https://bugs.launchpad.net/nova/+bug/1039386 as Don Dugger pointed out. That being said, as answers to some of your questions: yes, any key/value pair can be used and it is user's (in this case, system admin's) responsibility to avoid conflict at this time. The scope we originally thought was pretty much static like the number of GPUs, but there is no reason why it should be static as some features can change dynamically. I'd encourage you to propose a blueprint if you can. We can also consider the feature, but our team needs to discuss it before we can commit to it. Thanks, Joseph - Original Message - From: Patrick Petit patrick.michel.pe...@gmail.com To: Joseph Suh j...@isi.edu Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net, David Kang dk...@isi.edu Sent: Friday, August 24, 2012 7:37:31 PM Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications Hi Joseph and All, You are pointing the root cause of my question. The question is about how to specify capabilities for a compute node so that they can be compared with the extra specs. I think how to define extra specs in a flavor is clear enough. So, some capabilities are standard and are generated dynamically. Others are not known or not captured by the system and so not standard (yet), like the GPUs, and therefore must be specified somehow. Today, the somehow, as I understand things, is to add key/value pairs in nova.conf when/if it is supported. I wanted to make sure i understand the basic principals. Now, this in my opinion poses couple problems and/or call for additional questions: What is the naming convention to add capabilities in nova.conf? I would suppose that any key/value pair cannot be taken for a capability. How to avoid name clashing with standard capability? At the very least one should have an option to print them out (in nova-manage?). Even a simple written list would be helpful. But, are we really comfortable with the idea to define static capabilities in nova.conf? that's putting a lot of burden on config management. Also, not standard doesn't imply static. We can certainly live we that for now, But eventually, i think we'll need some sort of an extension mechanism so that providers can generate whatever capabilities they want using their own plugin? Note that capabilities could be software related too. What do you think? Best, Patrick Envoyé de mon iPad Le 24 août 2012 à 18:38, Joseph Suh j...@isi.edu a écrit : Patrick, Once a new item (key and value pair) is added to the capabilities, it can be compared against extra_specs. The extra_specs can be populated in instance_type_extra_specs table. The items in the extra_specs can start with one of the keywords for operations such as = and s==. For example, if ngpus: 4 is populated in capability, extra_specs of = 2 will choose the host. If the extra_specs is = 5, the host will not be chosen. If no keyword is found at the beginning of the extra_specs (with the latest change in upstream code), the given string is directly compared with capability. For example, if fpu is given as extra_specs, the capability must be fpu to be selected. If more clarification is needed, please let us know. Thanks, Joseph - Original Message - From: David Kang dk...@isi.edu To: Patrick Petit patrick.michel.pe...@gmail.com Cc: openstack@lists.launchpad.net (openstack@lists.launchpad.net) openstack@lists.launchpad.net Sent: Friday, August 24, 2012 11:34:11 AM Subject: Re: [Openstack] [Nova] Instance Type Extra Specs clarifications Parick, We are using the feature in Bare-metal machine provisioning. Some keys are automatically generated by nova-compute. For
Re: [Openstack] VM can't ping self floating IP after a snapshot is taken
for stable/essex the patach is here https://review.openstack.org/#/c/11986/, 2012/8/25 Sam Su susltd...@gmail.com: That's great, thank you for your efforts. Can you make a backport for essex? Sent from my iPhone On Aug 24, 2012, at 7:15 PM, heut2008 heut2...@gmail.com wrote: I have fixed it here https://review.openstack.org/#/c/11925/ 2012/8/25 Sam Su susltd...@gmail.com: Hi, I also reported this bug: https://bugs.launchpad.net/nova/+bug/1040255 If someone can combine you guys solution and get a perfect way to fix this bug, that will be great. BRs, Sam On Thu, Aug 23, 2012 at 9:27 PM, heut2008 heut2...@gmail.com wrote: this bug has been filed here https://bugs.launchpad.net/nova/+bug/1040537 2012/8/24 Vishvananda Ishaya vishvana...@gmail.com: +1 to this. Evan, can you report a bug (if one hasn't been reported yet) and propose the fix? Or else I can find someone else to propose it. Vish On Aug 23, 2012, at 1:38 PM, Evan Callicoat diop...@gmail.com wrote: Hello all! I'm the original author of the hairpin patch, and things have changed a little bit in Essex and Folsom from the original Diablo target. I believe I can shed some light on what should be done here to solve the issue in either case. --- For Essex (stable/essex), in nova/virt/libvirt/connection.py: --- Currently _enable_hairpin() is only being called from spawn(). However, spawn() is not the only place that vifs (veth#) get added to a bridge (which is when we need to enable hairpin_mode on them). The more relevant function is _create_new_domain(), which is called from spawn() and other places. Without changing the information that gets passed to _create_new_domain() (which is just 'xml' from to_xml()), we can easily rewrite the first 2 lines in _enable_hairpin(), as follows: def _enable_hairpin(self, xml): interfaces = self.get_interfaces(xml['name']) Then, we can move the self._enable_hairpin(instance) call from spawn() up into _create_new_domain(), and pass it xml as follows: [...] self._enable_hairpin(xml) return domain This will run the hairpin code every time a domain gets created, which is also when the domain's vif(s) gets inserted into the bridge with the default of hairpin_mode=0. --- For Folsom (trunk), in nova/virt/libvirt/driver.py: --- There've been a lot more changes made here, but the same strategy as above should work. Here, _create_new_domain() has been split into _create_domain() and _create_domain_and_network(), and _enable_hairpin() was moved from spawn() to _create_domain_and_network(), which seems like it'd be the right thing to do, but doesn't quite cover all of the cases of vif reinsertion, since _create_domain() is the only function which actually creates the domain (_create_domain_and_network() just calls it after doing some pre-work). The solution here is likewise fairly simple; make the same 2 changes to _enable_hairpin(): def _enable_hairpin(self, xml): interfaces = self.get_interfaces(xml['name']) And move it from _create_domain_and_network() to _create_domain(), like before: [...] self._enable_hairpin(xml) return domain I haven't yet tested this on my Essex clusters and I don't have a Folsom cluster handy at present, but the change is simple and makes sense. Looking at to_xml() and _prepare_xml_info(), it appears that the 'xml' variable _create_[new_]domain() gets is just a python dictionary, and xml['name'] = instance['name'], exactly what _enable_hairpin() was using the 'instance' variable for previously. Let me know if this works, or doesn't work, or doesn't make sense, or if you need an address to send gifts, etc. Hope it's solved! -Evan On Thu, Aug 23, 2012 at 11:20 AM, Sam Su susltd...@gmail.com wrote: Hi Oleg, Thank you for your investigation. Good lucky! Can you let me know if find how to fix the bug? Thanks, Sam On Wed, Aug 22, 2012 at 12:50 PM, Oleg Gelbukh ogelb...@mirantis.com wrote: Hello, Is it possible that, during snapshotting, libvirt just tears down virtual interface at some point, and then re-creates it, with hairpin_mode disabled again? This bugfix [https://bugs.launchpad.net/nova/+bug/933640] implies that fix works on spawn of instance. This means that upon resume after snapshot, hairpin is not restored. May be if we insert the _enable_hairpin() call in snapshot procedure, it helps. We're currently investigating this issue in one of our environments, hope to come up with answer by tomorrow. -- Best regards, Oleg On Wed, Aug 22, 2012 at 11:29 PM, Sam Su susltd...@gmail.com wrote: My friend has found a way to enable ping itself, when this problem happened. But not found why this happen. sudo echo 1 /sys/class/net/br1000/brif/virtual-interface-name/hairpin_mode I file a ticket to report this problem: https://bugs.launchpad.net/nova/+bug/1040255 hopefully someone can find why this happen and solve it. Thanks, Sam On Fri,
