| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-20 | |||
| 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 | |
| 14:59:00 | jaypipes | mriedem: thx for the link, ++. I should have time to get back to the perf improvement patches for CERN in nova-scheduler soon. sorry, between an offsite last week and some other things, been slammed of late. | |
| 14:59:35 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add known issue for minimum bandwidth resource leak https://review.openstack.org/644694 | |
| 15:00:17 | gibi | mriedem: thanks for that ^^ | |
| 15:00:21 | mriedem | np | |
| 15:00:29 | kashyap | mriedem: When you get a min, got a question for you (and the other Matt) on PS-11 here: https://review.openstack.org/#/c/641981/11 | |
| 15:00:35 | kashyap | (It's a quick one, though.) | |
| 15:04:16 | mriedem | kashyap: sure, split the docs kerfuffle out | |
| 15:04:28 | kashyap | mriedem: Thank you, sir | |
| 15:05:24 | kashyap | mriedem: I noted as such in the commit message (but not many read it, besides you :D). It requires a separate treatment. And writing high-quality docs take time. So I didn't wanted to mix it all in one.) | |
| 15:05:45 | mriedem | need another core for https://review.openstack.org/#/c/642863/ | |
| 15:05:50 | mriedem | which should probably happen before rc1 | |
| 15:29:08 | mriedem | lbragstad: mnaser: so based on mnaser's reply in the ML on the policy stuff with a read-only user, that would be something like just changing all GET policies in nova to require a reader role, yeah? rather than admin_or_owner type thing. | |
| 15:29:35 | mriedem | so non-admins could have the reader role, but not admin role, and admins would have both reader and admin role | |
| 15:30:01 | lbragstad | correct | |
| 15:30:28 | lbragstad | fwiw - keystone builds a relationship between the defaults roles we populate | |
| 15:30:30 | mriedem | and that could also be scoped to project, right? so readers in project A can't GET resources from project B | |
| 15:30:35 | lbragstad | right | |
| 15:31:01 | lbragstad | if someone has `reader` on the system, then they can view hypervisor information or whatever | |
| 15:31:24 | lbragstad | (is an example of how that would work outside of project scope) | |
| 15:31:27 | mriedem | ok, which is a good use case for support teams | |
| 15:31:32 | lbragstad | exactly | |
| 15:31:35 | lbragstad | or auditors | |
| 15:31:38 | mriedem | they can't delete hypervisors, but they can GET them | |
| 15:31:52 | lbragstad | also - when nova writes policies for this | |
| 15:32:00 | lbragstad | you only need to write it for the lower common denominator | |
| 15:32:09 | lbragstad | lowest* | |