| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-13 | |||
| 21:38:10 | sean-k-mooney | i know of at least 3 vendors who have done something in this space now so it would be nice to have a singel api in ovs for this. | |
| 21:38:31 | mriedem | bauzas: and you have one of these vif types | |
| 21:38:34 | mriedem | that set that config | |
| 21:38:56 | jangutter | sean-k-mooney, I definitely owe you your libation of choice. | |
| 21:38:56 | mriedem | bauzas: but yeah, they were picking up the latest newton patch release which regressed them | |
| 21:39:11 | bauzas | okay, anyway, +2d | |
| 21:39:25 | mriedem | cool thanks | |
| 21:39:42 | sean-k-mooney | jangutter: ah no worries im happy to help. | |
| 21:39:48 | dtp | can i get a ruling on https://blueprints.launchpad.net/nova/+spec/conf-network-metadata-always-static-ip, please? | |
| 21:40:05 | dtp | unsure what to do next w/ it | |
| 21:40:16 | mriedem | clarkb: mordred: are you interested in https://review.openstack.org/#/c/336293/ ? | |
| 21:40:37 | bauzas | mriedem: dansmith: I won't have time to correctly review https://review.openstack.org/#/c/456227/ but in case you don't land it tonight, I'll be reviewing it tomorrow morning my time | |
| 21:40:51 | mriedem | bauzas: i'll get it | |
| 21:40:58 | mriedem | with melwitt's help | |
| 21:41:04 | bauzas | k | |
| 21:42:36 | clarkb | mriedem: I want dhcp to be required :) | |
| 21:42:46 | clarkb | mriedem: which I think that sort of says it should be (as fallback?) | |
| 21:43:40 | sean-k-mooney | jangutter: strangly enough the reason we first looked at ovs manageing vf was so that we could manage sriov via odl for generic hardware. if you have smart nics that is even more valuable | |
| 21:43:52 | mriedem | dtp: can you answer clarkb's question? | |
| 21:44:05 | mriedem | dtp: clarkb and mordred are your ticket to config drive goodness | |
| 21:44:17 | jangutter | sean-k-mooney: heh, our very first OpenStack foray was with ODL! | |
| 21:46:05 | sean-k-mooney | my first encouter was deploying havana in the rc phase on centos 6.x with a beta version fo packstack. i obvioly did something bad in a past life | |
| 21:47:06 | jangutter | sean-k-mooney: wow. Mine was Liberty at least... | |
| 21:47:20 | mriedem | sean-k-mooney: it was punishment for bringing up 50 blueprint ideas at the ptg | |
| 21:47:27 | mriedem | all involving new scheduler filters or extra specs | |
| 21:48:20 | sean-k-mooney | mriedem: haha, it was worth it then | |
| 21:48:59 | dtp | clarkb i don't follow. do you mean static network configuration should never be used? | |
| 21:49:17 | jangutter | So, https://review.openstack.org/#/c/456386 has been thoroughly reviewed. Thank you so much! | |
| 21:49:39 | clarkb | dtp: it should never be required, I'm fine if you want to opt into it | |
| 21:51:02 | mriedem | jangutter: +2 | |
| 21:51:34 | dtp | clarkb in our network we prefer static config, but if you need dhcp for a first boot or something, we want to support that as well | |
| 21:52:00 | clarkb | dtp: its mostly convenience. Its something that just works everywhere | |
| 21:52:19 | clarkb | and doesn't require me to change/learn how every distro does network configuration | |
| 21:52:53 | sean-k-mooney | jangutter: out of interest looking at the poc code you have up across all the repos is that a working solution | |
| 21:52:58 | clarkb | but there are some cases (like link aggregation and vlans) where opting in might make sense as a user | |
| 21:53:06 | clarkb | *opting in to needing static config I should say | |
| 21:53:39 | sean-k-mooney | jangutter: it seams pretty small codewise of a failiy big performace bump though most of the really work is done in the nic/ovs | |
| 21:53:52 | jangutter | sean-k-mooney: it's working now on newton, but there's still something hinky that happens during live-migration. | |
| 21:53:54 | dtp | got to agree on that - it is a nice convenience. what change are you suggesting to this code? | |
| 21:54:32 | jangutter | sean-k-mooney: I have yet to track down why the pci address isn't being reallocated on the destination compute node. | |
| 21:54:48 | sean-k-mooney | jangutter: oh i might know why that is | |
| 21:55:05 | clarkb | dtp: I don't think it needs to change. at least my initial reading is this is compatbile with what I have said above | |
| 21:55:16 | clarkb | dtp: dhcp will still work. But nova might ask you to use static | |
| 21:55:17 | sean-k-mooney | jangutter: it has to do with the way nova has to rebind the port in migration | |
| 21:55:47 | sean-k-mooney | jangutter: it generates the libvirt xml for the destination before it calls to neutorn to rebind the host on the new host | |
| 21:55:55 | jangutter | sean-k-mooney: I have some scribblings a madman did here, something about "populate-neutron-binding-profile"... | |
| 21:56:04 | dtp | clarkb yessir. basically, just allowing nova to provide static config even if DHCP is enabled, is what it does. | |
| 21:56:23 | dtp | clients can use whichever they prefer | |
| 21:56:30 | sean-k-mooney | jangutter: as a result it does not update the pci adress before the xml is generated | |
| 21:57:10 | jangutter | sean-k-mooney: yes, exactly what we're seeing. Did that happen during Mitaka? | |
| 21:57:11 | sean-k-mooney | jangutter: yes as part of the port bind nova need to populate the neutron binging profile with the detail of the new vf | |
| 21:57:36 | sean-k-mooney | jangutter: yes it happened in mitaka | |
| 21:57:45 | sean-k-mooney | i think there is a spec to fix it | |
| 21:57:58 | sean-k-mooney | it came up as a topic in the nova neutron cross project session | |
| 21:58:04 | jangutter | wow, you just made my day.... | |
| 21:58:16 | jangutter | (only 2 minutes left!) | |
| 21:58:33 | sean-k-mooney | well i think there is a spec/bug for this i dont know if its fixed. | |
| 21:58:54 | sean-k-mooney | i belive the resolution involved allowing multiple port bindings during a live migrate | |
| 21:59:28 | mriedem | dtp: i left some comments/questions, | |
| 21:59:37 | mriedem | dtp: i'm green in this area so maybe my questions don't make sense | |
| 21:59:41 | jangutter | sean-k-mooney: would you know some keywords I can google? | |
| 21:59:53 | dtp | mriedem thanks! | |
| 22:00:57 | mriedem | melwitt: i'm +2 on https://review.openstack.org/#/c/456227/ - we need to get that in for p1 | |
| 22:01:01 | mriedem | but no pressure | |
| 22:01:04 | sean-k-mooney | jangutter: i belive its https://review.openstack.org/#/c/309416/ | |
| 22:01:26 | melwitt | mriedem: hah. looking at it now | |
| 22:02:06 | jangutter | sean-k-mooney: thanks! | |
| 22:03:59 | jangutter | would anyone else have cycles to do the final review on https://review.openstack.org/#/c/456386 ? | |
| 22:06:46 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Blacklist yasfb 0.6.0 https://review.openstack.org/456769 | |
| 22:06:57 | sean-k-mooney | jaypipes: perhaps you could take a skim over jangutter path https://review.openstack.org/#/c/456386 if you have time. form an os-vif point of view it makes sense to me. | |
| 22:12:01 | melwitt | mriedem: I think I'm missing how HostMappingNotFound is raised from things that don't appear to raise it | |
| 22:12:18 | mriedem | melwitt: the decorator | |
| 22:12:29 | mriedem | melwitt: which one specifically? | |
| 22:12:59 | melwitt | mriedem: like service_get_by_compute_host, but I see the decorator now. duh | |
| 22:13:05 | mriedem | ok | |
| 22:13:35 | melwitt | meaning duh to me, I wasn't seeing where the lookup was coming from | |
| 22:13:52 | mriedem | melwitt: i took that as a personal 'duh' to me | |
| 22:13:59 | mriedem | i was highly offended | |
| 22:14:00 | melwitt | I knew it! | |
| 22:19:25 | melwitt | mriedem: I don't see how it can be raised from the compute_node_get here https://review.openstack.org/#/c/456227/4/nova/api/openstack/compute/hypervisors.py@192 and then things could fail at L195 not raising the webob exception | |
| 22:26:44 | mriedem | melwitt: hmm yeah i don't see HostMappingNotFound raised from there either | |
| 22:27:14 | melwitt | not harmful for the except block, but harmful not to have the try-except around the other call that can raise it | |
| 22:27:47 | mriedem | well, it's not good to be handling exceptions that won't happen either | |
| 22:27:55 | mriedem | melwitt: want to -1? | |
| 22:28:07 | melwitt | yeah, I will. I'm just looking through the tests now | |
| 22:28:34 | melwitt | yes, agreed not good | |
| 22:50:07 | mriedem | dansmith: i don't want to pester but are we missing anything on https://review.openstack.org/#/c/456227/ ? | |
| 22:50:50 | dansmith | gdi you people | |
| 22:51:45 | dansmith | yeah I think I might've mixed up compute_get and service_get | |
| 22:51:53 | dansmith | ffs | |
| 22:52:20 | dansmith | I think I even explained it right in one of the earlier sets and then did the wrong thing | |
| 22:52:37 | melwitt | got too excited | |
| 22:54:23 | mriedem | it would be nice if we could just put a try/except around the entire os-hypervisors/os-services/os-hosts APIs | |
| 22:54:44 | mriedem | heh, you know, we actually could | |
| 22:55:49 | melwitt | now that would be sweet | |
| 22:56:50 | mriedem | well we do have a catch all place in the wsgi layer | |
| 22:57:32 | mriedem | this i think https://github.com/openstack/nova/blob/master/nova/api/openstack/wsgi.py#L396 | |
| 22:58:08 | mriedem | so, if we wanted to be lazy, we could just handle HostMappingNotFound there and return httpnotfound | |
| 22:58:11 | mriedem | melwitt: dansmith: ^ | |
| 22:58:15 | mriedem | kind of a cop out though | |