| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-21 | |||
| 17:14:50 | mriedem | damn it where is jaypipes | |
| 17:14:52 | efried | k, swhat I figured. | |
| 17:15:26 | mriedem | dansmith: edleafe: cdent: i've dumped comments on surya's 'locked_reason' spec - specific feedback on (1) the data model changes and (2) rest api payload format would be appreciated https://review.openstack.org/#/c/638629/ | |
| 17:15:37 | sean-k-mooney | kashyap: once rc1 is cut tonight it can be merged tommorow after the stable/stien branch is cut | |
| 17:15:50 | kashyap | mriedem: Yes, it is latent. | |
| 17:16:06 | sean-k-mooney | the real question is is it backportable | |
| 17:16:19 | cdent | mriedem: thanks queued | |
| 17:16:40 | kashyap | I definitely think it is backport-worthy. See mdbooth's comment earlier | |
| 17:17:19 | sean-k-mooney | kashyap: in which case it can be proposed for backport to stable/stien and the other stable branches | |
| 17:17:30 | sean-k-mooney | so its not really that much of an issue | |
| 17:17:30 | kashyap | mriedem_grooming: I don't agree with your emphatic "no". But whatever. I have 1000 other things that need my attention | |
| 17:17:52 | kashyap | sean-k-mooney: Yep, so it's fine, if it's merged tomm. | |
| 17:18:19 | sean-k-mooney | mdbooth: do you consider qemu vert type to be a bug | |
| 17:18:21 | kashyap | sean-k-mooney: But, I'd prefer it to be in Stein. I didn't "plan" this work. | |
| 17:18:45 | sean-k-mooney | mdbooth: you can say yes :) | |
| 17:18:48 | mdbooth | kashyap: I don't think it's worthy of Stein at this stage. | |
| 17:18:55 | kashyap | mdbooth: Okido... | |
| 17:18:56 | mdbooth | kashyap: Focus on the backport. | |
| 17:19:05 | kashyap | I don't know; I'll focus on dinner first | |
| 17:19:11 | mdbooth | kashyap: Good call :) | |
| 17:19:47 | kashyap | sean-k-mooney: mdbooth: But as noted, The two volume drivers patches should _also_ merge at the same time | |
| 17:19:54 | kashyap | For the "minimum possible doc" to make sense. | |
| 17:24:25 | mriedem_grooming | listen guys, i didn't say it wasn't a bug, i sait it wasn't a regression in stein, it's latent, therefore it doesn't need to be held up for rc1 which is already stressful | |
| 17:24:30 | mriedem_grooming | so we'll deal with backports | |
| 17:24:48 | mriedem_grooming | if people don't like my input on it then don't ask | |
| 17:25:45 | kashyap | mriedem_grooming: Hey, I do like your input very much :-) | |
| 17:26:14 | efried | I was content at :14:52 | |
| 17:26:17 | kashyap | mriedem_grooming: But yep, please go ahead with RC1 stuff (after your grooming) | |
| 17:27:08 | sean-k-mooney | efried: what change ad 14:53 | |
| 17:27:13 | sean-k-mooney | * at | |
| 17:27:52 | kashyap | sean-k-mooney: If I have to guess it's the "not an RC1 candidate" remark :-) | |
| 17:27:57 | efried | :14:52, as in 14 mins 52s after whatever hour you're in (Unless you're in one of those bizarre time zones that's off by a half hour) | |
| 17:28:08 | efried | when I said "k, swhat I figured". | |
| 17:28:36 | sean-k-mooney | oh ha i see | |
| 17:29:01 | efried | which was shorthand for, "I was pretty sure this wasn't a candidate for rc1, but I wasn't positive, so I asked mriedem. He voiced a similar opinion. So that is what we shall go with." | |
| 17:29:35 | bauzas | honestly, not a big deal (again) | |
| 17:29:59 | bauzas | we always cut RC1 after things we wanna wait | |
| 17:30:21 | bauzas | the question is : should the bug we discuss be in the waitlist ? obviously not in my mind, period | |
| 17:30:39 | sean-k-mooney | efried: by the way have you looked at the nova ptg etherpad to see what should be moved to placemetn or nova placement cross project stuff | |
| 17:30:57 | efried | sean-k-mooney: Yes, I did that yesterday, but it will need constant mriedem_groominging | |
| 17:31:30 | efried | could have been Tuesday | |
| 17:31:49 | efried | no, yesterday: http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004030.html | |
| 17:32:07 | sean-k-mooney | efried: i originally adde the resource provider yaml but topic but is that something that anyone is going to pursue in train? | |
| 17:32:33 | efried | sean-k-mooney: IMO that's a straight-up Nova topic, as it doesn't ask for any changes to the placement API. | |
| 17:32:52 | sean-k-mooney | oh sorry yes it is | |
| 17:32:55 | efried | I haven't felt a whole lot of excitement behind that effort, so I haven't been pushing it. | |
| 17:33:03 | efried | but if you're excited, I'll get excited with you. | |
| 17:33:11 | efried | since I proposed the thing | |
| 17:33:13 | sean-k-mooney | i partly context switch and was wondering if there was still a desire to discuss it | |
| 17:34:10 | sean-k-mooney | well i think there is a pain point there but im not sure if that is the solution | |
| 17:34:40 | efried | Had this revelation recently when talking about https://etherpad.openstack.org/p/placement-inter-provider-affinity -- would rather do small, simple, easy-to-understand things that have limited scope and power than try to do a super generic one-size-fits-all thing. | |
| 17:34:50 | efried | and that yaml spec leans much more toward the latter. | |
| 17:35:43 | sean-k-mooney | ok. im going to grab lunch too. | |
| 17:37:06 | bauzas | oh man, I'm getting mad at devstack deployments | |
| 17:37:25 | sean-k-mooney | bauzas: something specificlly? | |
| 17:39:04 | bauzas | neutron fails to install | |
| 17:39:10 | bauzas | but meh, I'll fix it | |
| 17:39:17 | sean-k-mooney | ah ok | |
| 17:40:38 | bauzas | yeah, it's a reqs thing | |
| 17:41:43 | bauzas | let's go for a RECLONE=yes | |
| 17:45:01 | NobodyCam | fyi incase anyone ever runs in to this again: issue was bad rabbit ip in nova_api/cell_mappings.transport_url | |
| 17:52:18 | dansmith | efried: cdent: what's the status on this eventlet monkeypatch thing? I saw some discussion this morning, but when I looked the other day it had changed since my review for reasons I wasn't sure about | |
| 17:52:37 | efried | dansmith: tldr we think it's good, but wait for after rc1 | |
| 17:53:03 | dansmith | efried: ah right, because they said it was okay in train, cool | |
| 17:53:04 | efried | dansmith: was gonna bug you tomorrow (after rc1 cut) to re-up your +2 | |
| 17:53:18 | efried | well, they want it backported. We just don't want to drop it into rc1 | |
| 17:53:27 | dansmith | right | |
| 17:59:19 | melwitt | mriedem_grooming, efried: thanks for getting the cycle highlights updated | |
| 17:59:34 | efried | yw | |
| 18:09:38 | efried | our last rc1 patch just hit the 2h mark unstarted in the check queue :( | |
| 18:29:04 | openstackgerrit | Merged openstack/nova master: Move libvirt calculation of machine type to utils.py https://review.openstack.org/644554 | |
| 18:41:40 | openstackgerrit | melanie witt proposed openstack/nova master: Move creation of rpcapi.ComputeAPI object from __init__ https://review.openstack.org/644998 | |
| 18:44:16 | openstackgerrit | melanie witt proposed openstack/nova master: Move create of ComputeAPI object in websocketproxy https://review.openstack.org/644998 | |
| 18:45:36 | jroll | afaik there is no way to limit the project(s) which can boot an instance on a given set of compute nodes, right? surely someone has proposed this before, is it a hard no? | |
| 18:49:11 | dansmith | tenant isolation yo! | |
| 18:50:20 | dansmith | jroll: new placementy way to do it: https://specs.openstack.org/openstack/nova-specs/specs/rocky/implemented/placement-req-filter.html | |
| 18:50:36 | dansmith | jroll: also an old filter-based approach (google for filter_tenant_id) | |
| 18:50:36 | jroll | oooo | |
| 18:51:53 | jroll | dansmith: this should work perfectly, thanks! | |
| 18:52:13 | dansmith | finally, FINALLY, I do something to make jroll happy. | |
| 18:52:20 | jroll | it only took 5 years | |
| 18:52:32 | dansmith | better late than never | |
| 18:53:32 | sean-k-mooney | the tenant isolation filter has some edgecases | |
| 18:54:24 | sean-k-mooney | the main one being it limits the set of host a project can boot instnace on but does not prevent other project form booting instnaces on those same host | |
| 18:54:50 | dansmith | sean-k-mooney: you should read that spec | |
| 18:55:21 | dansmith | there's a provision (unlike the filter approach) that will reject if the tenant is not confined, so you can avoid that situation | |
| 18:56:05 | mriedem | melwitt: did you want to re-propose the counting quotas spec so we can line that up for landing early in train? | |
| 18:56:09 | sean-k-mooney | oh cool. well it was not really a edgecase in the old filter i guess as a desing choice | |
| 18:56:13 | mriedem | the code i mean, after the spec is re-approved | |
| 18:56:26 | sean-k-mooney | dansmith: nice to know the placement version accounts fot that | |
| 18:56:38 | melwitt | mriedem: oh, yes, I do. thanks for reminding me | |
| 18:57:08 | melwitt | let me do it now so I don't forget a third time | |
| 18:58:54 | jroll | dansmith: the use case mentions segregate users into cells, but it sounds like the solution only depends on aggregates, not cells, am I reading that right? | |
| 18:59:58 | mriedem | the scheduler does might be more clear than the spec https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#tenant-isolation-with-placement | |
| 19:00:01 | mriedem | *docs | |
| 19:00:32 | jroll | mriedem: thanks, that answers it | |
| 19:00:39 | dansmith | jroll: correct | |
| 19:01:40 | sean-k-mooney | jroll: the original usecase was a cellv1 -> cellv2 perfromcne regration which is why the spec focused on cells but ya it just needs aggreates | |
| 19:01:54 | jroll | sean-k-mooney: right, figured as much | |
| 19:01:57 | openstackgerrit | melanie witt proposed openstack/nova-specs master: Re-propose count quota usage from placement https://review.openstack.org/645302 | |