| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 13:46:43 | mdbooth | Ok, ^^^ is the one. Really. | |
| 13:46:59 | mdbooth | stephenfin: How do you feel about the sphinx bodge in ^^^ ? | |
| 13:47:30 | stephenfin | mdbooth: It's necessarily awful | |
| 13:47:42 | mdbooth | stephenfin: Why thank you | |
| 13:47:48 | stephenfin | :) | |
| 13:47:57 | kashyap | aspiers: Looks good to me. | |
| 13:48:08 | aspiers | kashyap: thanks | |
| 13:48:57 | mdbooth | If there's any other way which doesn't involve moving entry points, and therefore impacting deployment tooling, I'd do that instead. | |
| 13:49:15 | mdbooth | It's kinda icky, but it's the best I can think of. | |
| 13:50:32 | stephenfin | mdbooth: It'll do for 6 months, I imagine | |
| 13:50:41 | stephenfin | at which point we should be aiming to rip that all out | |
| 13:51:13 | mdbooth | stephenfin: Yarp. | |
| 13:51:20 | efried | that's a new one on me, thanks mdbooth | |
| 13:51:27 | mdbooth | efried: dirty hack that works | |
| 13:51:42 | mdbooth | efried: Code I'm not proud of | |
| 13:51:44 | sean-k-mooney | mdbooth: is the bodge hardcoding OS_NOVA_DISABLE_EVENTLET_PATCHING in the conf.py | |
| 13:52:06 | mdbooth | sean-k-mooney: Both that, and requiring it at all | |
| 13:55:11 | mdbooth | Wait, I think I just did think of a better way | |
| 13:55:13 | sean-k-mooney | i was going to leave a review comment but honestly my tastae for anyting in this patch can be adressed in train. assuming this works and the gate is happy i think this is good enough for stien | |
| 13:55:44 | efried | mriedem: Care to re-wordsmith https://review.openstack.org/#/c/644412/4/releasenotes/notes/stein-prelude-b5fe92310e1e725e.yaml@57 ? Or I can take a stab at it, but you know the reward for good work... | |
| 13:55:46 | mdbooth | Ok, there's another version coming which eliminates that. | |
| 13:55:50 | sean-k-mooney | condtionally setining it if not set instead of hardcoding | |
| 13:56:05 | sean-k-mooney | e.g. by usign the defualt valude on the get call | |
| 13:56:10 | mdbooth | We originally did: from nova import utils; utils.monkey_patch() | |
| 13:56:52 | mdbooth | Oh, wait. I got excited too early. | |
| 13:56:55 | mdbooth | It doesn't work. | |
| 13:57:41 | sean-k-mooney | well provied v11 which is currently up works that is proably good enough for now | |
| 13:57:44 | mdbooth | I was thinking that explicitly executing monkey_patch() from the importing module bought us something, but of course it doesn't because it's still executed at import time. | |
| 13:57:54 | mdbooth | ...which is why I removed that in the first place. | |
| 13:58:02 | sean-k-mooney | ah ya | |
| 14:02:09 | mriedem | efried: replied | |
| 14:02:16 | mriedem | tl;dr i don't think it's worth re-writing | |
| 14:07:23 | efried | mriedem: I seem to be having a hard time conveying what I think the reader is going to care about here. And maybe it's because they really won't care about it. | |
| 14:08:09 | efried | mriedem: The release notes are about more than the upgrade process itself, aren't they? | |
| 14:08:42 | mriedem | yeah, major new features and such | |
| 14:08:48 | mriedem | and highlighting major upgrade impacts, | |
| 14:08:51 | efried | I mean, | |
| 14:09:16 | efried | I guess if you're going to go switch on the QoS feature, you'll read the docs for that and... not be surprised when multiple providers appear. | |
| 14:09:45 | mriedem | sure, but those already using vgpu + libvirt might never enable qos | |
| 14:09:54 | mriedem | so i'd rather not conflate the features | |
| 14:10:57 | cdent | efried: do people poke placement? is that a thing? | |
| 14:11:00 | efried | right, so I was focusing not on the specific features and more on the structural change they have in common. A structural change that operators may notice | |
| 14:11:36 | efried | cdent: Based on conversations overheard with vexxhost and cern folks, it seems like they do. | |
| 14:12:06 | cdent | dunno about vexxhost but my experience with cern it is with regard to what the service is doing, not the count of resource providers | |
| 14:12:08 | efried | ...and precisely because the features otherwise seem unrelated, this prelude would be a good place to write about the thing that ties them together. | |
| 14:12:09 | mriedem | cdent: they do when shit goes wrong and they are trying to debug | |
| 14:12:29 | mriedem | so how about, | |
| 14:12:33 | efried | yeah, so when they do that and oh crap there's suddenly two or more providers for my host, that must be wrong, freak out | |
| 14:12:35 | cdent | yes, and all of that has little to with reading a release notes prelude, I would have thought. that's what I'm trying to understand | |
| 14:13:11 | efried | if they read the prelude, ever, they might remember in the back of their head that this might possibly be a normal thing, and dig further before pushing the red button. | |
| 14:13:14 | cdent | if you can grep for 'resource provider' anywhere in the release notes then that's enough | |
| 14:13:43 | cdent | yeah, the "ever" is key, and why I think it is to "go back to release notes after something weird happened" | |
| 14:13:49 | cdent | "and grep" | |
| 14:14:00 | efried | mm | |
| 14:14:23 | mriedem | "Nova now supports nested resource providers in two cases: 1. QoS-enabled ports will have resource allocates created on a nested resource provider from the start. 2. Libvirt compute nodes reporting VGPU inventory will have that VGPU inventory and corresponding allocations moved to a child resource provider on restart of the nova-compute service after upgrading to Stein. - In both cases this means when looking at resource prov | |
| 14:14:24 | mriedem | s, depending on scenario, you can see more than one provider where there was initially just a root compute node provider per compute service." | |
| 14:14:28 | mriedem | efried: how is that ^? | |
| 14:14:47 | efried | mriedem: love it | |
| 14:14:52 | efried | s/allocates/allocated/ | |
| 14:14:56 | efried | allocations | |
| 14:15:03 | efried | sed fail | |
| 14:15:51 | mriedem | like cdent said, if the release notes for the changes themselves were clear in the reno we likely wouldn't need the big prelude, but o-) | |
| 14:16:01 | mriedem | ideally, the vgpu reno would have a before and after osc output | |
| 14:16:29 | mriedem | showing the VCPU/MEMORY_MB/DISK_GB inventory on the root provider and the VGPU inventory on the child provider after the reshape | |
| 14:16:37 | mriedem | or, | |
| 14:16:42 | mriedem | we can still build that into the docs | |
| 14:16:56 | mriedem | i.e. "if things are working properly, you can expect to see something like this" | |
| 14:17:09 | mriedem | somewhere in here https://docs.openstack.org/nova/latest/admin/virtual-gpu.html | |
| 14:17:50 | mriedem | personally i don't love putting a ton of detail in release notes anyway - details should be in docs since those are indexed and don't get lost in the sands of time, and then renos can just link to said docs | |
| 14:18:08 | mriedem | people FFU past the release notes anyway | |
| 14:18:50 | mriedem | hell https://docs.openstack.org/nova/latest/admin/virtual-gpu.html should probably already say something about nested provider trees starting in stein | |
| 14:18:53 | efried | mriedem: Right, like I said before, the notes for the changes themselves could (and the docs for said changes certainly should) mention the nrp-ness; but they're tied together by this substantial architectural shift (and basically nothing else), and IMO that's worth mentioning, and this is the place to do it. | |
| 14:19:16 | mriedem | sure, if you want, just take what i proposed above and pretty it up | |
| 14:22:14 | efried | mriedem: done, should I edit and repropose or let melwitt do it? | |
| 14:23:10 | mriedem | https://bugs.launchpad.net/nova/+bug/1821015 | |
| 14:23:11 | openstack | Launchpad bug 1821015 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova - libvirt reshaping" [Medium,Triaged] | |
| 14:23:19 | mriedem | efried: i'd say go ahead and modify yourself | |
| 14:26:21 | lbragstad | at some point this week - i'm wondering if we can sit down and hash out http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003894.html | |
| 14:26:55 | mriedem | lbragstad: you and who's army? | |
| 14:27:22 | lbragstad | just me, myself, and i | |
| 14:27:35 | mriedem | i didn't read the whole thread but i thought you and melwitt were hashing it out | |
| 14:27:41 | mriedem | dansmith: efried: jaypipes: fyi https://techblog.web.cern.ch/techblog/post/placement-requests/ | |
| 14:27:53 | mriedem | nice write up from belmoreira on the refresh associations stuff in their rocky upgrade | |
| 14:28:04 | mriedem | nice to see that feedback loop working ^ | |
| 14:28:07 | lbragstad | well - i think we're going to need to involve the foundation at some point to correct the sessions | |
| 14:28:30 | lbragstad | otherwise we risk splitting the audience with two similar sessions | |
| 14:30:30 | mriedem | are you going to make me read this thread? | |
| 14:31:46 | mriedem | can you do the general keystone sessions at the forum with an emphasis on what nova is planning to do, and then the nova specific details get hashed out at the ptg? | |
| 14:32:27 | mriedem | i don't even know if johnthetubaguy is going to be attending for https://www.openstack.org/summit/denver-2019/summit-schedule/events/23715/feedback-gathering-for-unified-limits-proposal | |
| 14:33:47 | mriedem | lbragstad: is what i just suggested what you already came to in the ML thread? | |
| 14:34:02 | mriedem | i was really hoping to not have to put my leadership underwear on today | |
| 14:34:44 | lbragstad | well there are duplicate forum sessions for rbac and unified limits | |
| 14:35:16 | lbragstad | i think melwitt wanted to have the nova session be specific to the unified limit and policy migrations for now - but i expect a lot of other services are going to be in that same boat | |
| 14:36:00 | lbragstad | originally, i think we were planning on using the forum sessions to communicate relevant information about what has been done for each initiative to operators, and leave the developer-specific topics for the PTG | |
| 14:38:41 | mriedem | here you go http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004026.html | |
| 14:39:22 | mriedem | if a split nova-specific session is just going to be crickets, then i don't think it's worth doing a forum session, just leave it for the ptg if devs want to talk about it | |
| 14:39:51 | mriedem | this is why i didn't actually propose a nova session for unified limits myself | |
| 14:40:47 | lbragstad | ack - thanks for responding | |
| 14:41:16 | mriedem | probably not the response you're looking for, but it's a reason to justify combining sessions | |
| 14:41:45 | mriedem | if jaypipes cares about this (by proxy for verizon) i'm not sure if he's going to be at the forum either | |