Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-06-13
14:59:31 mgagne mriedem: so I'm mostly at a point where I can test your patch. I had to upgrade Ironic to Queens too in order to be able to start nova-compute (which requires a recent Ironic API) to populate placement with provider resources.
15:00:06 mriedem yeah ironic always goes before nova
15:00:08 mgagne BUT I find something surprising. Could it be that nova-compute already auto-heal allocations on startup?
15:00:26 openstackgerrit Eric Fried proposed openstack/nova master: Update nova-status & docs: require placement 1.25 https://review.openstack.org/575140
15:00:32 mriedem mgagne: computes < pike would create allocatiosn
15:00:39 openstackgerrit Eric Fried proposed openstack/nova master: Enforce placement minimum in nova.cmd.status https://review.openstack.org/568965
15:00:43 mriedem well, newton and ocata computes configured to talk to placement would create allocations
15:00:53 mriedem mgagne: but i thought you were going directly from mitaka to queens?
15:01:08 mgagne 17.0.4 is queens right?
15:01:22 mgagne mriedem: yes I am, running queens now
15:01:28 mriedem 17.0.5 at this point, but yeah
15:01:45 mriedem i wonder if you have any stale nova-compute services in the cell db?
15:02:01 mgagne 17.0.5 already? oh well
15:02:13 mriedem because just one will trigger the auto-heal https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1217
15:02:27 mriedem mgagne: check to see if you have any services records in the cell db that are version < 22
15:02:46 mriedem OH
15:02:52 mriedem if these are ironic computes, then those auto-heal
15:02:56 mriedem https://github.com/openstack/nova/blob/master/nova/compute/resource_tracker.py#L1225
15:02:59 mgagne hmm, yes I'm hitting that code path
15:03:02 melwitt mriedem: okay, thanks
15:03:02 mgagne "Compute driver requires allocation refresh. Will auto-correct allocations to handle Ocata-style assumptions."
15:03:15 mriedem mgagne: yeah that's for your ironic nodes
15:03:24 mgagne hilarious...
15:03:31 mriedem mgagne: but how about libvirt nodes?
15:04:12 mgagne we don't use caching with libvirt in our product... well, we do but in a private cloud elsewhere
15:04:35 mgagne and without cells but I guess it's irrelevant
15:05:17 mgagne so I would have to test this specific case. so back to tests
15:08:16 mriedem mgagne: so you use cells v1 + ironic + caching scheduler,
15:08:29 mriedem but not cells v1, libvirt and filter scheduler elsewhere?
15:09:41 mriedem mgagne: also note that in queens, the IronicHostManager and Exact* filters are deprecated for ironic
15:09:49 mriedem actually pike, but ...
15:15:21 openstackgerrit Eric Fried proposed openstack/nova master: Update nova-status & docs: require placement 1.25 https://review.openstack.org/575140
15:15:22 openstackgerrit Eric Fried proposed openstack/nova master: Enforce placement minimum in nova.cmd.status https://review.openstack.org/568965
15:17:11 openstackgerrit Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204
15:17:12 openstackgerrit Brianna Poulos proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269
15:17:13 openstackgerrit Brianna Poulos proposed openstack/nova master: Add certificate validation docs https://review.openstack.org/560158
15:17:14 openstackgerrit Brianna Poulos proposed openstack/nova master: WIP: Add trusted certs to feature support matrix docs https://review.openstack.org/574890
15:17:15 openstackgerrit Brianna Poulos proposed openstack/nova master: Remove max_size parameter from fake_libvirt_utils.fetch_*image methods https://review.openstack.org/574911
15:19:27 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Add status and links fields to version document at / https://review.openstack.org/575117
15:20:19 mriedem gibi: i don't know when bdm.no_device is useful :)
15:20:36 mriedem i think it's some legacy bdm v1 / ec2 carryover
15:20:55 gibi mriedem: me neither so fair enough :)
15:21:21 mgagne mriedem: yes, that's right: CellsV1 + Ironic + Caching. CellsV1 + libvirt + filter elsewhere. (and no cells + libvirt + Caching in our private cloud)
15:27:01 openstackgerrit Chris Dent proposed openstack/nova master: [placement] replace deprecated accept.best_match https://review.openstack.org/575127
15:30:52 melwitt I'm going to be out next week and need someone to run the nova meeting June 21 at 21:00 UTC. is there anyone who can help with that?
15:34:30 mriedem i'm out wed-fri next week so not it
15:34:54 mriedem i nominate dansmith or efried
15:35:55 openstackgerrit Chris Dent proposed openstack/nova master: [placement] Add status and links fields to version document at / https://review.openstack.org/575117
15:37:15 openstackgerrit Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405
15:37:16 openstackgerrit Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407
15:37:17 openstackgerrit Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604
15:37:18 openstackgerrit Jay Pipes proposed openstack/nova master: Fix nits from change Id609789ef6b4a4c745550cde80dd49cabe03869a https://review.openstack.org/574324
15:39:23 dansmith next week, the 21st which is a late meeting right?
15:40:04 dansmith melwitt: if you'll update the agenda so I just have to parrot it then I'll be your huckleberry
15:43:00 melwitt dansmith: yes, it's the 21:00 UTC, 2pm PST one. will update the agenda on friday (there's a chance runways will change next week tho). thank you for the help
15:43:42 dansmith melwitt: then I will parrot incorrect runway information
15:44:08 dansmith melwitt: I recommend you get a cell connection and laptop so you can update it from the bush if you want it to be correct
15:44:29 melwitt thanks for the tip :P
15:44:49 dansmith heh
15:47:47 openstackgerrit Eric Fried proposed openstack/os-vif master: doc: Mention second arg to (un)plug in usage doc https://review.openstack.org/575151
15:49:01 efried Anyone feel like giving me a quick overview of what os-vif/os-brick are and how the fit into the world?
15:49:14 efried This is something I have been putting off knowing for too long.
15:49:28 mriedem connect vifs and volumes on the host
15:49:36 mriedem for various backends
15:49:54 mriedem </end>
15:50:07 dansmith checks out
15:50:07 efried mriedem: Does one subclass stuff out of those libs for specific platforms or whatever?
15:50:26 mriedem probably not, you'd put a connector in brick
15:50:34 mriedem there are platform-specific connectors in brick
15:50:38 mriedem for windows and p and z
15:50:55 efried mriedem: but not in os-vif
15:51:09 efried that one has just ovs and lb
15:51:09 mriedem os-vif has vif type specific objects
15:51:17 mriedem os-vif can load up plugins
15:51:25 mriedem so vendor vif type plugins don't need to be in the os-vif repo
15:51:29 mriedem just loaded via stevedore extension point
15:51:34 mriedem like jangutter's
15:51:49 mriedem os-brick doesn't use versioned objects, and os-vif does,
15:52:05 mriedem the long-term / ideal with os-vif is nova/neutron can pass around versioned serialized versions of os-vif objects
15:52:35 mriedem rather than neutron throwing a random bag-o-dicts at nova in the port binding profile and other random dicts and nova just trusting things might not be there and handling if so for upgrades
15:53:15 mriedem so nova can say, here is this version of this ovs object that i'm plugging into this host for this port, and neutron will make that object compatible for the version of os-vif it understands
15:53:38 jangutter An os-vif object gets handled by two things: Nova passes it to the hypervisor to say "hey, plug this into the instance", it also passes it to the os-vif 3rd (or 1st) party plugin to say "hey, plug this into the datapath".
15:54:07 efried Do you have an example of one of these plugin thingies?
15:54:24 jangutter There's reference plugins in the os-vif repo for things like Linuxbridge and OVS.
15:54:31 mriedem efried: this is the defailed spec for os-vif https://specs.openstack.org/openstack/nova-specs/specs/newton/implemented/os-vif-library.html
15:54:52 mriedem https://github.com/6WIND/os-vif-plugin-vhostuser-fp
15:54:55 jangutter Sometimes the os-vif plugin thingy is basically a null operation (libvirt does everything, say).
15:55:00 mriedem https://github.com/bigswitch/os-vif-bigswitch
15:55:11 mriedem https://github.com/bigswitch/os-vif-bigswitch/blob/master/setup.cfg#L26
15:55:27 mriedem register an os_vif extension point with the vif type namespace key
15:55:29 efried "passes it to the hypervisor" via e.g. plug_vifs in the ComputeDriver API?
15:55:30 mriedem 'ivs' in this case
15:56:14 efried Thanks guys.
15:56:21 jangutter efried: I think so, libvirt has a conversion layer for VIFs inside Nova.
15:56:31 mriedem plug_vifs takes the network info list of vifs (ports) and translates those to os-vif objects which for libvirt then gets converted to interface configs, which go into the guest xml
15:56:57 mriedem the actual 'plug' call in os-vif on the object is the datapath thing i think?
15:57:32 efried edmondsw: Do we have (plans for) integration of networking-powervm into os-vif?
15:57:37 jangutter mriedem: yeah 'plug' and 'unplug' calls into the os-vif plugin that's been registered.
15:57:52 efried ...or am I still completely misunderstanding how this ties in?
15:58:23 efried networking-powervm provides, uh, ml2 plugin (or is it agent) and, uh, mech driver (or is it agent/plugin)

Earlier   Later