Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
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*
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"

Earlier   Later