| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-25 | |||
| 22:21:54 | sean-k-mooney | if you delete it in neutron the send an event to nova which causes it to be detach form the vm | |
| 22:22:08 | mriedem | bzzt! | |
| 22:22:20 | mriedem | the nova code relies on getting the allocation information from the port's binding:profile | |
| 22:22:27 | mriedem | so if the port is deleted, we can't very well look it up | |
| 22:22:59 | sean-k-mooney | well it should be in the network info cache but yes that might be an issue | |
| 22:23:08 | mriedem | so either neutron needs to cleanup the allocation, or we have to store information about the allocation in the info cache | |
| 22:23:13 | mriedem | none of this is in the info cache | |
| 22:23:21 | mriedem | none of the requested resources / allocations stuff | |
| 22:23:40 | mriedem | i've asked gibi about that a few times, i.e. "you know if we just stored x in the info cache we could use it here rather than calling neutron" | |
| 22:24:00 | sean-k-mooney | i had tought the vif:port_profile was in the vif object in the info cache but maybe not. i havent looked at it in a while | |
| 22:24:38 | melwitt | dansmith: well, I'm not sure who would request one, but I thought maybe the detach root volume bp or volume-backed rebuild, or other smaller things like adding numa topo or server group to 'nova show' | |
| 22:24:47 | mriedem | sean-k-mooney: oh i guess it is, the binding:profile that is | |
| 22:24:55 | mriedem | i'm not sure it would be up to date... | |
| 22:25:10 | mriedem | melwitt: the volume backed rebuild isn't happening i don't tink | |
| 22:25:11 | mriedem | *think | |
| 22:25:14 | sean-k-mooney | we sore https://github.com/openstack/nova/blob/master/nova/network/model.py#L378-L400 | |
| 22:25:19 | dansmith | melwitt: okay both of those seemed to be too far and too large to be FFE material to me, | |
| 22:25:21 | sean-k-mooney | which has the profile in it | |
| 22:25:26 | dansmith | but granted I've been a bit disconnected | |
| 22:25:30 | mriedem | and i'll be talking about root volume detach with Kevin_Zheng tonight but there are going to be issues with that as well | |
| 22:25:50 | dansmith | to me, FFE is for the final push for something that is almost done and I guess nothing pops out in my head at the moment as obviously fitting that description | |
| 22:25:59 | mriedem | sean-k-mooney: yeah i know yo'ure right, so we might be able to handle the port getting deleted there | |
| 22:26:06 | mriedem | sean-k-mooney: if the cache is up to date | |
| 22:26:18 | melwitt | looks like the FFE process is supposed to kick in the week after freeze anyway, so I guess I'm thinking about it too early https://docs.openstack.org/nova/latest/contributor/process.html#non-priority-feature-freeze | |
| 22:26:35 | mriedem | well how many weeks are there between FF and RC1? | |
| 22:26:47 | mriedem | if it's 2, there isn't really time for FFE unless like dansmith it's a low risk change that is already there | |
| 22:27:03 | melwitt | 2 | |
| 22:28:14 | melwitt | ok. last cycle I didn't raise the FFE process because I assumed there wasn't enough time and this time I wanted to make sure I brought it up | |
| 22:28:22 | sean-k-mooney | so the event we get i think will be a network-vif-unplugged event which is handeled by the periodic task the updated the network info cache. we might be able to hook that event in the periodic job to do the clean up | |
| 22:29:00 | sean-k-mooney | i can try and take a look at that code tomrrow. im a bitt too tired to look this evening | |
| 22:29:48 | mriedem | is it network-vif-unplugged or network-changed? | |
| 22:29:55 | mriedem | because we do different things in that ase | |
| 22:29:58 | mriedem | *case | |
| 22:30:52 | mriedem | anyway, i left comments on https://review.openstack.org/#/c/622421/ so gibi can sort it out and at least leave TODOs to handle those | |
| 22:30:59 | sean-k-mooney | i think you will get both. you will get an network-vif-unpluged for the ovs agent when it tears down the port and a newtork-changed event form the deletion | |
| 22:31:27 | openstackgerrit | Yongli He proposed openstack/nova master: Adds the server group info into show server detail API. https://review.openstack.org/621474 | |
| 22:31:29 | mriedem | oh i was talking about the case that someone (the admin?) sets the device_id on the port to None/'' | |
| 22:31:39 | mriedem | so the port isn't deleted, it's just detached from the server | |
| 22:32:00 | mriedem | granted one should probably never do that, and cinder doesn't allow you to detach like that (unless you force it) | |
| 22:33:51 | sean-k-mooney | oh am a.) the whould not do that :) and b.) ... i can test that tomorrow and let you know what happens. neutron will allow note allow you to set it to the python None but it will allow you to set it to the string "None" | |
| 22:34:08 | sean-k-mooney | * a.) they should not... | |
| 22:41:08 | mriedem | melwitt: the api change for this is merged https://review.openstack.org/#/c/636779/ so if you get a minute can you review the novaclient change, it should be pretty simple | |
| 22:41:12 | mriedem | i'm taking that one out of runways though | |
| 22:41:22 | mriedem | takashin: ^ | |
| 22:41:37 | melwitt | mriedem: ok, can do. thanks | |
| 22:42:11 | takashin | mriedem: Okay. I will review it. | |
| 22:42:20 | mriedem | thanks | |
| 22:43:58 | openstackgerrit | Merged openstack/nova master: Send RP uuid in the port binding https://review.openstack.org/569459 | |
| 22:44:14 | openstackgerrit | Merged openstack/nova master: Test boot with more ports with bandwidth request https://review.openstack.org/573317 | |
| 22:47:35 | openstackgerrit | Merged openstack/nova master: Use placement.inventory.inuse in report client https://review.openstack.org/568639 | |
| 22:50:59 | melwitt | congratulations :) | |
| 22:50:59 | melwitt | py27: commands succeeded | |
| 22:51:05 | melwitt | *eyes shimmering* | |
| 22:53:17 | sean-k-mooney | melwitt: :) what patch are you working on ? | |
| 22:53:34 | melwitt | counting quota usage from placement | |
| 22:53:47 | melwitt | when I see those green messages it's just like.... yess | |
| 22:53:57 | sean-k-mooney | and that is always nice to see but it kill me when pythone 3 fails after python 2 passes | |
| 22:54:13 | melwitt | oh yeah. that's bitten me before | |
| 23:02:00 | openstackgerrit | Chris Friesen proposed openstack/nova master: Flavor extra spec and image properties validation https://review.openstack.org/620706 | |
| 23:04:02 | yonglihe | mriedem: just rebase to new microversion. zuul running. | |
| 23:04:23 | mriedem | yonglihe: yup i saw | |
| 23:04:26 | cfriesen | FYI, in the context of this ^ commit, I'm taking over from jackding. | |
| 23:05:32 | sean-k-mooney | cfriesen: ok. are you the only windriver person working on nova currently again? | |
| 23:06:34 | sean-k-mooney | cfriesen: als that is targetign train right? stephen has reproposed the spec for train | |
| 23:06:50 | cfriesen | sean-k-mooney: there are a couple other guys that will hopefully pop their heads up. :) | |
| 23:07:10 | cfriesen | sean-k-mooney: that's targetting stein and is currently on a runway | |
| 23:07:25 | cfriesen | sean-k-mooney: stephen proposed a whole separate thing for train | |
| 23:07:35 | sean-k-mooney | oh ok | |
| 23:07:54 | sean-k-mooney | ill also try and review that tomorrow so. | |
| 23:08:04 | sean-k-mooney | anyway ill call it a day there o/ | |
| 23:08:35 | cfriesen | sean-k-mooney: I just took a quick look at it, need to review it fully. looks like he's proposing defining a proper generic schema for the various properties/extra-specs | |
| 23:08:50 | cfriesen | sean-k-mooney: later | |
| 23:08:57 | sean-k-mooney | stephenfin: spec | |
| 23:09:18 | sean-k-mooney | ya so there is a glance api we could already use | |
| 23:09:43 | sean-k-mooney | but we migth want to seperate it out into a reusable lib or something | |
| 23:10:25 | sean-k-mooney | he would like to have a single source to both use for validation and documentaiton generation acorss favor extraspec/image metatdata/volume metadata | |
| 23:10:50 | sean-k-mooney | the glance metadef api does that allready but he is also considering other options | |
| 23:17:35 | openstackgerrit | Yongli He proposed openstack/nova master: Add server sub-resource topology API https://review.openstack.org/621476 | |
| 23:18:05 | aspiers | who's our resident KVM / machinetype expert? | |
| 23:18:21 | aspiers | I've just discovered a snag with SEV detection | |
| 23:19:28 | aspiers | libvirt's virConnectGetDomainCapabilities() API requires specifying a particular arch and machine type | |
| 23:19:52 | mriedem | aspiers: hook up with kash | |
| 23:19:53 | mriedem | kashyap | |
| 23:19:57 | aspiers | mriedem: thanks | |
| 23:20:30 | aspiers | so the results presumably could vary per architecture and machine type, although in practice it seems that if the SEV feature is supported, it is supported across all (arch, machine type) pairs the host provides | |
| 23:21:31 | aspiers | but in order to detect the SEV capability (and provide a trait), this API call needs to be done during initHost() where arch/machtype is not known, rather than just before booting an instance when it is known | |
| 23:22:21 | aspiers | since currently this getDomainCapabilities API call is only used for SEV detection and nothing else, I could hardcode it to x86_64 and a single machine type | |
| 23:22:27 | aspiers | but that seems a bit ugly | |
| 23:23:15 | aspiers | or I could call it once for each (arch, machine type) the host provides, and then if SEV is supported for any one of those tuples, mark the SEV capability as supported for the host | |
| 23:24:37 | aspiers | but kashyap isn't currently here it seems ... | |
| 23:32:32 | melwitt | kashyap is EU time zone | |
| 23:33:38 | aspiers | melwitt: OK thanks | |
| 23:36:41 | cfriesen | aspiers: don't we specify arch in the nova config? | |
| 23:37:37 | aspiers | cfriesen: I don't think so | |
| 23:38:46 | aspiers | but actually it's only one of two possibilities in the libvirt driver | |
| 23:39:13 | aspiers | cfriesen: https://github.com/openstack/nova/blob/c7f0d160e4df95cc82706bcd8c4a9890a4dfeb51/nova/virt/libvirt/driver.py#L438 | |
| 23:39:34 | aspiers | so I can iterate over those two, but that still leaves the question of machine type | |
| 23:39:44 | aspiers | of which there are a zillion | |
| 23:39:52 | cfriesen | aspiers: ah...I was actually thinking of the "hw_machine_type" config option | |
| 23:40:02 | aspiers | ah yeah, that's different | |