| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-02-25 | |||
| 22:03:07 | sean-k-mooney | mriedem: right so we always defered part of it to after stien | |
| 22:03:25 | sean-k-mooney | cfriesen: right but i assume you would like to fix those edgecase in trian? | |
| 22:03:55 | sean-k-mooney | cfriesen: or rather you would like them to be fix but dont nessisarily want to have to be the one to fix them :) | |
| 22:03:55 | cfriesen | sean-k-mooney: I personally would love to. I don't think shelve is a big deal for our customers though. | |
| 22:03:59 | mriedem | windriver doesn't shelve so it doesn't matter to them | |
| 22:05:23 | sean-k-mooney | so to summerise i get that the preference would be to punt unless both cold/live migrate and resize work by the end of the week? | |
| 22:06:44 | mriedem | i only have personal preferences | |
| 22:07:00 | mriedem | and right now i feel the crushing weight of a deluge of last minute blueprints that need review right before FF | |
| 22:07:48 | dansmith | seriously, why are we even considering adding something we know we haven't fully implemented and thus can't move? | |
| 22:08:02 | dansmith | we already have an embarrassing number of "yeah this works, BUT YOU CAN NEVER MOVE IT" things, IMHO | |
| 22:08:11 | sean-k-mooney | dansmith: well live migration should work | |
| 22:08:26 | sean-k-mooney | its just cold/rezise but fair point | |
| 22:08:59 | sean-k-mooney | for livemigrat qemu copies the vtpm data iteslf but for cold we have to do it if i remember correctly | |
| 22:10:01 | melwitt | mriedem: I guess this convo is as good segue as any to something I was thinking about, FFE process. do we want to do the ML post, etherpad request, sponsor gathering process we have done in the past? | |
| 22:10:11 | dansmith | sean-k-mooney: so just the thing that *most* users will be able to trigger? | |
| 22:11:09 | sean-k-mooney | dansmith: yes. i am actully feeling that we should punt unless it works too but it also seams quite small | |
| 22:11:33 | sean-k-mooney | works -> is feature complete includign move operations | |
| 22:13:12 | sean-k-mooney | cfriesen: in anycase if you have someting that works im happy to test it with the other live migration feature im planning to test. | |
| 22:13:24 | cfriesen | sean-k-mooney: appreciated. | |
| 22:13:31 | sean-k-mooney | cfriesen: i get the feeling all of them will be punted to train m1 however | |
| 22:13:57 | cfriesen | :) | |
| 22:16:03 | sean-k-mooney | if we can get numa/sriov/cross-cell migration landed in m1 with vtpm and bandwith mover opertion that would be a.) alot of work and b.) alot of valuable features landed early/late depending on your view point | |
| 22:17:55 | dansmith | melwitt: what are the things that are realistically candidates for FFE? | |
| 22:20:43 | mriedem | jaypipes: good question on "wtf happens if the port is detached (or deleted) out of band while it has allocations" | |
| 22:20:51 | mriedem | jaypipes: i replied, but tl;dr - we don't handle it, | |
| 22:21:00 | mriedem | and it really kind of sucks that we (nova) are the ones managing that | |
| 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 | |