| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-09 | |||
| 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 | |
| 16:27:29 | melwitt | ok he already added them, thanks | |
| 16:28:01 | mriedem | lyarwood: should i start reviewing https://review.openstack.org/#/c/587013/ again or do you expect more from mdbooth/ | |
| 16:28:02 | mriedem | ? | |
| 16:28:37 | lyarwood | mriedem: that should be good now | |