| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 13:29:37 | efried | I didn't mean to cut anyone out, sorry. | |
| 13:29:42 | bauzas | no worries | |
| 13:30:06 | bauzas | just for the next release, we open the prelude change 2 days before and we leave it there at least some time | |
| 13:30:14 | efried | noted, thank you. | |
| 13:39:08 | aspiers | kashyap: https://review.openstack.org/#/c/644554/ is ready for review | |
| 13:39:41 | aspiers | efried: anyone else I should add to review for that? ^^ | |
| 13:39:46 | openstackgerrit | Matthew Booth proposed openstack/nova master: Eventlet monkey patching should be as early as possible https://review.openstack.org/626952 | |
| 13:43:14 | mdbooth | It's going to be revised in a second ;) | |
| 13:43:35 | mdbooth | Line length violations after I indented everything and forgot to rerun pep8 | |
| 13:45:02 | efried | aspiers: Dunno. Maybe bauzas would like to look :) | |
| 13:45:30 | bauzas | I can | |
| 13:45:49 | efried | thanks bauzas. Should be an easy one, just a refactor (and an extra log) | |
| 13:46:01 | aspiers | and extra tests!! \o/ | |
| 13:46:40 | openstackgerrit | Matthew Booth proposed openstack/nova master: Eventlet monkey patching should be as early as possible https://review.openstack.org/626952 | |
| 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 | |