Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
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*
15:32:32 lbragstad for example, GET /v2/hypervisors would be "role:reader" for the policy check string
15:33:07 lbragstad and if a system administrator calls that API, they will actually have `admin`, `member`, and `reader` in their token - since `admin` implies `member` and `member` implies `reader`
15:33:09 mriedem and scope_types has to be set to 'system' for that also?
15:33:16 lbragstad eventually, yet
15:33:18 lbragstad yes*
15:33:28 mriedem so what about the case where people aren't using scope types yet?
15:33:40 mriedem but want reader roles in their policy, but not expose hypervisor details to non-admins
15:34:17 mriedem or is that not really an option?
15:34:23 lbragstad in that case, we have to add a little extra to the check string for each policy (only until we can assume the migration is over and we've communicated things to operators)
15:34:34 lbragstad "role:reader and system_scope:all" would solve that
15:34:43 lbragstad without having enforce_scope=True
15:35:04 mriedem do you envision we'd have two policy files for awhile, the existing one for backward compat, and a "this is the new fancy stuff which is here to use if you want, but it's experimental for now" kind of thing?
15:35:35 lbragstad i wouldn't recommend that approach - we tried that in keystone a long time ago and it didn't turn out too well imo
15:36:17 lbragstad instead, i would evolve the existing policies to account for those cases, like check_str="(role:reader and system_scope:all) or rule:admin_or_owner"
15:36:19 mriedem ok i don't have a good grasp on what the proposed migration looks like
15:36:39 mriedem i'm assuming the recommendation is to start migrating piece meal
15:36:59 lbragstad that's how we're doing it in keystone, yeah
15:37:21 mriedem i'm also assuming there is a summit video somewhere about the migration process?
15:37:39 lbragstad we're going to resource individually, adding a whole bunch of protection tests so we catch regressions, and then adjusting the policies accordingly
15:37:46 lbragstad going through*
15:38:20 lbragstad there have been forum sessions on the migration approach in the past, but nothing has been recorded afaik
15:40:02 mriedem ok, that could also be done with a recorded youtube session like these old ones that sdague used to organize https://wiki.openstack.org/wiki/BootstrappingHour
15:40:08 mriedem i wish we'd start doing more of those again
15:40:25 lbragstad i have done something similar for this work in the past, but not the migration
15:42:16 openstackgerrit Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625
16:08:48 bauzas mriedem: efried_rolling: FWIW, I left https://review.openstack.org/#/c/644412/5 waiting for other reviews, we could just +W it tonight EOB if you want
16:08:57 bauzas ie. US folks EOB I mean
16:09:19 bauzas that leaves melwitt, dansmith or other West Coast folks to balance if needed
16:09:51 mriedem ack
16:23:47 openstackgerrit Dan Smith proposed openstack/nova-specs master: Add request-filter-image-types spec https://review.openstack.org/644625
16:24:36 gmann lbragstad: mriedem do we really need system_scope=all ? until enforce_scope=false scope_type will not be checked just log warning so operator will have time to consume the scope_type things
16:25:46 gmann I mean as we have configuration variable to enable/disable the scope_type then, we can directly do "role:reader", scope_type: 'system'
16:29:30 kashyap What are the other volume drivers besides: Quobyte, Virtuozzo, SMBFS?
16:30:21 lbragstad gmann i think we do need "role:reader and system_scope:all", especially in the case where we are applying that to things like hypervisors
16:30:37 lbragstad otherwise we could accidentally open the hypervisor API up to anyone with the reader role on anything
16:31:14 lbragstad since the check string would be "role:reader or rule:admin_or_owner" instead of "(role:reader and system_scope:all) or rule:admin_or_owner"
16:47:58 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable https://review.openstack.org/641981
16:47:59 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: smbfs: Use 'writeback' QEMU cache mode https://review.openstack.org/643377
16:47:59 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: vzstorage: Use 'writeback' QEMU cache mode https://review.openstack.org/643376
16:48:50 kashyap mdbooth: ^ Has the bare-minimum doc update. For the volume drivers text: the 'vzstorage' and 'smbfs' patch should also merge along with the main patch -- for the "doc to tell the truth"
16:49:17 mdbooth kashyap: Thanks
16:49:20 cfriesen kashyap: everything under virt/libvirt/volume?

Earlier   Later