Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-09
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 mriedem there is nothing immediately obviously different between mitaka and queens in how binding:host_id is handled,
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: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
16:15:37 mriedem the bigger docs series is what really matters
16:15:40 mriedem but that's not ready for rc1
16:15:40 efried I can try to rip out a reno real quick
16:15:48 melwitt ok, inline fix it and approve is cool with me then
16:16:04 mriedem you can always do the docs in rc2
16:16:13 efried mriedem: I'll do the grammar fix and push it.
16:16:18 mriedem ack
16:16:34 openstackgerrit Eric Fried proposed openstack/nova master: Add a prelude release note for the 18.0.0 Rocky GA https://review.openstack.org/589303
16:16:40 melwitt ok, I wasn't sure if a docs-only thing was rc2 worthy. if it is, then we can do that
16:17:35 efried melwitt, mriedem: done. If we're not worried about getting the reno landed today, I'll happily wait for jichenjc to do it.
16:18:26 mriedem i'm not losing sleep over a detailed reno for the zvm driver which does a very small number of things - the docs are more important to me
16:18:30 mriedem the prelude mentions it
16:18:37 mriedem if someone wants to learn more, they can find the driver docs
16:19:29 mriedem the way i look at renos, if it's really detailed, it likely needs to be a doc, because release notes are a one time only thing
16:22:08 mriedem melwitt: should probably hold up stable releases on https://review.openstack.org/#/q/topic:bug/1784705+status:open
16:22:30 melwitt ok, that's helpful. fwiw, I was thinking basic detail in the reno like, what operations are supported (spawn, destroy, snapshot, get console output, power actions)
16:22:35 melwitt mriedem: ok, will do
16:22:39 mriedem anyone using ironic + ComputeCapabilitiesFilter will be hit by those
16:22:53 mriedem melwitt: supported ops for the zvm driver are in the feature support matrix
16:22:58 mriedem so i wouldn't put that in the reno
16:23:16 melwitt ok. efried, we don't need an additional reno ^
16:24:14 efried Okay, wfm. jichenjc, in case you're snooping later ^
16:24:31 efried The prelude could have linked to the admin config doc, if it was landed, but it ain't, so...
16:26:41 melwitt based on what mriedem said, we can have a rc2 because of the docs, and land them there
16:27:10 melwitt so I'll add those to https://etherpad.openstack.org/p/nova-rocky-release-candidate-todo

Earlier   Later