Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
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
14:41:55 lbragstad i'm fine keeping them separate if there is a reason to
14:42:03 lbragstad but i'm also fine consolidating them
14:42:14 mriedem lbragstad: is there anything you're not fine with? :)
14:42:57 lbragstad lol - if we keep them separate sessions, i wouldn't be fine with people getting confused over which one to attend ;)
14:43:22 mriedem you could do like a carnival barker standing outside your session
14:43:38 mriedem "one day only folks, gather round gather round"
14:44:01 lbragstad i'll see if i can recruit someone to do that
14:44:09 lbragstad s/recruit/bribe/
14:44:21 mriedem ayoung with a sax?
14:44:57 lbragstad only if smooth jazz gets you in the mood to discuss policy and unified limits
14:45:08 mriedem smooth jazz gets me in the mood for everything
14:46:58 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP] Revert resize: wait for external events in compute manager https://review.openstack.org/644881
14:46:58 openstackgerrit Artom Lifshitz proposed openstack/nova master: Revert "Wait for network-vif-plugged on resize revert" https://review.openstack.org/639396
14:51:37 openstackgerrit Eric Fried proposed openstack/nova master: Add a prelude release note for the 19.0.0 Stein GA https://review.openstack.org/644412
14:51:43 efried mriedem et al ^
14:51:46 mriedem bauzas: fyi if you can take a stab at this https://bugs.launchpad.net/nova/+bug/1821015
14:51:47 openstack Launchpad bug 1821015 in OpenStack Compute (nova) "Attaching virtual GPU devices to guests in nova - libvirt reshaping" [Medium,Triaged]
14:52:30 bauzas mriedem: no worries, I'll write docs
14:52:48 bauzas I was also planning to talk about reboot issues
14:53:25 mriedem efried: +2

Earlier   Later