| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-13 | |||
| 20:52:42 | sean-k-mooney | jangutter: well the vif object definition should go in os-vif even for external plugins | |
| 20:52:48 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Amend spec for placement project/user association https://review.openstack.org/454352 | |
| 20:53:02 | sean-k-mooney | jangutter: that is to ensure we all have a common set of datamodels | |
| 20:53:19 | jangutter | sean-k-mooney: yep, agreed, but it would still be acceptable? | |
| 20:53:40 | sean-k-mooney | createing the port profiles in os-vif yes | |
| 20:54:46 | sean-k-mooney | jangutter: the changes to vif_plug_ovs in https://review.openstack.org/#/c/456483/ should be done in an external os-vif plugin | |
| 20:54:46 | jangutter | forgive me if I'm operating a bit on the wonky side, I claim a severe lack of sleep and the wrong timezone... | |
| 20:56:10 | sean-k-mooney | the changes to the os_vif objects should got to os-vif | |
| 20:56:38 | jangutter | OK, so an extra task would be: create a new external plugin (replicating what the OVS plugin does). | |
| 20:56:56 | sean-k-mooney | jangutter: yes but only replicating the part you need | |
| 20:57:30 | sean-k-mooney | os-vif was structured so that you can clone it and the cp one of the plugin sub directos and use that as the base for a new plugin. | |
| 20:58:04 | jangutter | Yep, I noticed that too, it's pretty awesome. | |
| 20:58:26 | sean-k-mooney | jangutter: of example i dont think you need to support iptables/hybrid plug in you case correct | |
| 20:58:46 | jangutter | Correct: that part of the kernel is short-circuited. | |
| 20:59:03 | jangutter | We do support the ovs conntrac rules on the chip though. | |
| 20:59:10 | sean-k-mooney | so the plugin itself should be failly small | |
| 20:59:13 | sean-k-mooney | cool | |
| 20:59:37 | jangutter | Thanks, amending spec. | |
| 21:00:05 | sean-k-mooney | contrack should not effect the plug dirver code though. if you want me to review the plugin or help you with it let me know | |
| 21:00:20 | mriedem | nova meeting itme | |
| 21:00:21 | mriedem | *time | |
| 21:00:24 | mriedem | in #openstack-meeting | |
| 21:15:01 | openstackgerrit | Jan Gutter proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386 | |
| 21:23:42 | sean-k-mooney | mriedem: that was a short and sweet meeting | |
| 21:23:43 | jangutter | sean-k-mooney: yep, nova is blithely oblivious to conntrack. | |
| 21:28:19 | bauzas | mriedem: I guess https://review.openstack.org/#/c/448253/ is very latent for Ubuntu given they still provide an old libvirt ? | |
| 21:29:46 | openstackgerrit | Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavor API https://review.openstack.org/449288 | |
| 21:30:27 | openstackgerrit | Rick Bartra proposed openstack/nova master: Add policy granularity to the Flavor API https://review.openstack.org/449288 | |
| 21:31:59 | sean-k-mooney | jangutter: minor nit in latest version of https://review.openstack.org/#/c/456386/9 but otherwise this looks good to me | |
| 21:32:19 | jangutter | The main reason I left that in there was to coordinate with the Mellanox guys. | |
| 21:32:30 | bauzas | mriedem: yeah confirmed, xenial LTS is having libvirt-1.3.1 http://packages.ubuntu.com/xenial/libvirt-bin | |
| 21:32:32 | mriedem | bauzas: yes, outside of UCA | |
| 21:32:44 | mriedem | bauzas: we regressed ubuntu with a fix for centos 7.3 | |
| 21:32:47 | mriedem | that assumed a newer libvirt | |
| 21:32:54 | mriedem | which was ok for centos, but broke xenial | |
| 21:32:54 | bauzas | okay | |
| 21:32:59 | mriedem | so we straddle the versions now | |
| 21:33:00 | jangutter | sean-k-mooney: If we can come up with a common standard, it might get us that much closer to upstream by default into OVS. | |
| 21:33:34 | sean-k-mooney | jangutter: ya the melonox work seams to be getting traction upstream in ovs | |
| 21:34:03 | bauzas | mriedem: so, if you deploy Nova on Xenial without using the UCA packages, then kaboom, correct? | |
| 21:34:19 | sean-k-mooney | if you are able to make that work for ye then all of these changes could go into the openvswitch plugin in os-vif | |
| 21:35:31 | jangutter | sean-k-mooney: yep, but the TC stuff is kernel hackery, and the bar for merging that is VERY high. | |
| 21:36:27 | sean-k-mooney | ya i know we have looked at doing something similar with dpdk in the past | |
| 21:36:51 | sean-k-mooney | we canceled those nics though so that got pushed back | |
| 21:37:36 | jangutter | sean-k-mooney: As have we. The funny thing is that there doesn't seem to be something at this stage that does everything well. | |
| 21:37:50 | jangutter | *looked at DPDK. | |
| 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 | |