Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-13
20:50:15 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Spec to enable Netronome SmartNIC support https://review.openstack.org/456386
20:50:24 mriedem jangutter: you should be fixed now
20:50:28 mriedem just need to address sean-k-mooney's comments
20:50:40 jangutter Thanks.
20:50:49 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Add a new section: "Upgrade impact" to the template https://review.openstack.org/456756
20:51:58 sean-k-mooney mriedem: jangutter my only real feedback is on the logation fo the os-vif code. if its not upstream in the main ovs repo the pluging changes need to be in an external plugin
20:52:05 jangutter sean-k-mooney: I understand that the VIF types would likely need to be forked because we're not upstream (yet).
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 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: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: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 bauzas okay
21:32:54 mriedem which was ok for centos, but broke xenial
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 mriedem bauzas: but yeah, they were picking up the latest newton patch release which regressed them
21:38:56 jangutter sean-k-mooney, I definitely owe you your libation of choice.
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.

Earlier   Later