Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-09
14:49:53 mriedem after about 7 years of being broken
14:50:31 mdbooth Got it. I did a bit of an audit here, btw: https://review.openstack.org/#/c/587071/9/nova/tests/unit/conductor/test_conductor.py@1004
14:51:00 mriedem I8b1c05317734e14ea73dc868941351bb31210bf0
14:52:12 mriedem yeah so we'll call _cleanup_volumes which will detach if we abort the build
14:52:14 mriedem but not if we reschedule
14:52:23 mriedem and conductor doesn't do any volume cleanup on MaxRetriesExceeded
14:52:29 mriedem so that's probably a separate bug,
14:52:46 mriedem and would benefit from a functional test since it involves more than a single service
14:52:57 mriedem (really 3 - conductor and 2 computes for the reschedule)
14:53:21 mriedem we might already have a func test that does reschedules with a volume attached
14:54:46 mriedem i don't see one though
14:54:48 mriedem but shouldn't be hard to write
14:58:50 lyarwood mdbooth: https://review.openstack.org/#/c/587014/ does that
14:59:28 mdbooth lyarwood: Thought I'd seen it recently :)
15:00:14 hvvcben the API call, i.e "binding:host_id": "mymitkaComputehost",
15:00:14 hvvcben Hi - probably a newb question and if this isn't the correct channel please advise. - I am trying to rework an old neutron ML2 driver into Queens and having issues with Nova-compute during port creation. Because of no bind_host_id = $nodeID during instance create. The nova-compute api call to neutron to create port it doesn't have the bind_host_id set in the api call. On older version like Mitaka, that parameter is in
15:00:25 hvvcben any help or links to doc pertaining to these changes would be greatly appreciated
15:03:20 mriedem melwitt: is your link to irc in https://review.openstack.org/#/c/589972/ wrong?
15:04:35 melwitt oh, yeah it is now because I used "latest". derp. I think I've done that a few times lately
15:05:59 melwitt added a new comment with the right link
15:06:18 hvvcben mitka api nova-compute api to neutron = "binding:host_id": "mymitkaComputehost", Queens nova-compute api call to neutron more like "binding:host_id": "",
15:06:31 mriedem hvvcben: i see bind_host_id in the neutronv2/api.py code in queens
15:06:43 mriedem are you saying bind_host_id isn't being passed down from the compute manager to allocate_for_instance?
15:07:09 mriedem i think that was only ever used by the ironic driver
15:07:09 hvvcben yes,
15:08:04 mriedem it's still used in queens https://github.com/openstack/nova/blob/stable/queens/nova/compute/manager.py#L1390
15:08:06 hvvcben I am just having trouble figuring out why it does it in mitaka and not in later version, I was thinking the port creation process has been modified and that value would come later in the process
15:08:10 mriedem but as i said, that would only ever have a value for ironic
15:09:44 hvvcben this particular driver does interact with hardware and in its present state fails if no Host_id is passed
15:10:02 hvvcben hardware meaning switch hardware
15:11:17 mriedem the only difference i see when setting binding:host_id between mitaka and queens is that in mitaka we only set that if the neutron port binding extension was available, and we stopped looking for that sometime later and just assumed it would be available
15:11:21 hvvcben i was just curious, since i have default install of mitaka and it passes it(using openvswitch as driver) and the queens version doesn't was there some point where that was changed? Thats what I am having trouble finding. I thought it may relate to livemigration
15:11:43 mriedem you said you're trying to create an instance, not live migrate it, right?
15:12:35 hvvcben yes yes, but I thought their were some rework done on port creation that affected nova and neutron dealing with port creation as a whole in effort to smooth out live migrations
15:12:35 mriedem there is nothing immediately obviously different between mitaka and queens in how binding:host_id is handled,
15:12:38 mriedem so you're going to have to debug
15:12:46 mriedem that's in rocky
15:12:48 hvvcben yes been trying
15:13:00 mriedem maybe you mean the migrating_to stuff?
15:13:02 mriedem for dvr
15:13:14 mriedem if you're not live migrating, you wouldn't hit any of that so shouldn't be a problem
15:14:10 hvvcben gotcha. has the port creation process changed significantly from mitaka to queens?
15:14:45 hvvcben as far as what nova do etc?
15:16:40 mriedem you're talking about like a 2 year window of dev here :)
15:16:52 mriedem i'm not aware of anything significant changing in that flow in that time though, no
15:17:04 hvvcben : ) I know i know
15:17:15 mriedem are you sure you're not using now-invalid config in queens?
15:17:28 mriedem like, we could have deprecated some config options in mitaka/newton and they are gone by the time you get to queens
15:17:52 hvvcben ... appreciate i will dig further.. I just mainly need to find a way to get the nova-compute host_id and pass it to neutron in a way during create_port_precommit
15:18:55 mriedem which virt driver are you using?
15:18:56 mriedem libvirt?
15:18:57 mriedem https://github.com/openstack/nova/blob/mitaka-eol/nova/virt/driver.py#L1587
15:19:01 hvvcben probably all of the above... -- the driver was designed to work with Mitaka and not maintained their have been quite a bit of changes in neutron since then obviously(in a good way)
15:19:14 hvvcben yes it is libvirt
15:19:15 mriedem https://github.com/openstack/nova/blob/stable/queens/nova/virt/driver.py#L1657
15:19:36 mriedem the only other thing i can think is by the time we call network_binding_host_id in the compute manager, the instance.host field isn't set yet
15:20:32 hvvcben yea i think that may be part of a port staging process now where back then it was more like "Create it right now"
15:20:36 mriedem melwitt: i'm +2 on the reno https://review.openstack.org/589303 and the rpc alias https://review.openstack.org/589972 so you will need to bug another core
15:20:48 melwitt mriedem: ack, thanks
15:22:34 mriedem hvvcben: shouldn't have changed this, the ResourceTracker.instance_claim sets the instance.host,
15:22:40 mriedem and that happens before we start the network allocation stuff
15:22:58 openstackgerrit Jay Pipes proposed openstack/nova master: split gigantor SQL placement query into multiple https://review.openstack.org/590041
15:22:59 openstackgerrit Jay Pipes proposed openstack/nova master: placement: use simple code paths when possible https://review.openstack.org/590388
15:25:21 hvvcben thanks mriedem: thanks for the assistance
15:26:03 mriedem dansmith: replied in https://review.openstack.org/#/c/590062/
15:26:08 mriedem hvvcben: np, good luck
15:27:13 openstackgerrit Eric Fried proposed openstack/nova master: Nix 'new in 1.19' from 1.19 sections for rp aggs https://review.openstack.org/590389
15:29:49 openstackgerrit Lee Yarwood proposed openstack/nova master: fixtures: Track volume attachments within CinderFixtureNewAttachFlow https://review.openstack.org/587013
15:29:50 openstackgerrit Lee Yarwood proposed openstack/nova master: Add regression test for bug#1784353 https://review.openstack.org/587014
15:29:51 openstackgerrit Lee Yarwood proposed openstack/nova master: conductor: Recreate volume attachments during a reschedule https://review.openstack.org/587071
15:31:54 dansmith mriedem: ah dang, I saw update_cells and stopped reading
15:32:15 dansmith thinking that was just the v1 sync thing like instance save
15:32:19 dansmith so nevermind
15:39:36 mriedem lyarwood: can you hit this? https://review.openstack.org/#/c/590062/
15:43:36 lyarwood mriedem: yup looking
15:53:14 melwitt mriedem: I just happened upon the patch for adding the zvm driver to the support matrix https://review.openstack.org/532720
15:53:47 melwitt other doc updates are stacked on top
15:54:55 melwitt and I found that no reno was added for the zvm driver at the time of the changes, so I think someone needs to add that
15:55:54 mriedem if you want it, it's likely going to have to be you
15:55:58 mriedem jichen is probably gone for the day
15:56:11 melwitt yeah. I was thinking that, given the time factor
15:56:44 openstackgerrit Jay Pipes proposed openstack/nova master: placement: use simple code paths when possible https://review.openstack.org/590388
15:56:45 openstackgerrit Jay Pipes proposed openstack/nova master: split gigantor SQL placement query into multiple https://review.openstack.org/590041
16:04:26 openstackgerrit Eric Fried proposed openstack/nova master: Adds a test for _get_provider_ids_matching() https://review.openstack.org/590150
16:10:00 mriedem -1 on the zvm feature support matrix patch
16:10:11 mriedem so if we do an rc2, the zvm docs and such might need to fall into that
16:10:43 melwitt ack
16:11:29 mriedem the only mention that it was added will be in your prelude reno
16:12:57 melwitt I know ... I'm writing up it's own reno based on the patches, and hopefully efried can help. I would like it to have its own reno with the details and not have the only mention be in the prelude
16:13:21 melwitt I didn't realize it was missing a reno of its own
16:13:59 mriedem ok, i personally don't think we should hold up https://review.openstack.org/#/c/589303/ on that,
16:14:00 mriedem but ok
16:14:14 efried I would only be guessing in writing up that reno. I guess it prolly needs to be done by EOB though, huh?
16:14:23 efried mriedem: No, I agree, I was holding on the other issue.
16:14:51 mriedem the grammar nit?
16:14:58 mriedem then let's just fix it inline and approve?
16:15:05 efried yeah, sounds good.
16:15:10 mriedem melwitt: ^?
16:15:13 melwitt mriedem: you think it's ok for that to be the only mention? if so, I'm fine with it. you know a lot more about this than I do
16:15:29 mriedem i'm fine with it

Earlier   Later