Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-20
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?
16:50:49 gmann lbragstad: ok. make sense until enforce_scope is not removed or defaulted to True.
16:51:36 mnaser lbragstad, mriedem: late but better than ever, i tried hacking a little bit on what it would look like and i was also unsure of how an ideal transition path might look like
16:51:50 gmann lbragstad: so in that case requested cred will have to add system_scope=all for such request then only they are auth otherwise not
16:52:17 mnaser i think the concern is bob's openstack deployment who hasn't deleted their policy.json file or is currently overriding a few things that finds themselves exposing a lot of things after an upgrade
16:54:11 lbragstad mnaser how so?
16:54:18 gmann mnaser: any policy rule overridden in policy.json file will keep working as it is because we will add old policy rule as deprecated_rule in new rules. But yes if anyone reply on policy in code default thing then they will see this impact
16:54:26 lbragstad because their overrides are obsolete?
16:55:15 mnaser lbragstad: if someone had role:support to GET hypervisor list, and now we updated it that they need system scope now for that specific policy
16:55:23 mnaser they find themselves with a non functional policy at that point i guess
16:55:59 mnaser yeah i think the concern is that it would break existing policies
16:56:00 lbragstad if they have a special role for listing hypervisors and an override for that policy, then it should still work even if we change the default
16:56:13 gmann yeah
16:59:30 gmann if bob reply on GET hypervisor with default policy which is say "admin" currently, we will change this to say "role:reader and system_scope:all" or something which control it not to expose to non-admin
17:01:49 mnaser lbragstad: if we change the scope to system, wouldn't it stop working then.. because that role is probably project scoped?
17:01:55 mnaser project scoped to the 'admin' tenant
17:02:12 lbragstad roles aren't scoped to projects per se
17:02:45 lbragstad roles can be associated to actors on targets, actors can be groups or users, and targets can be projects, domains, or system
17:03:13 mnaser right, but bob's openstack cloud probably has it targeting projects right now, as 99% of our docs have always said
17:03:26 mnaser "if you want to give a role for X, create a project and add X role to Y user into it"
17:03:41 gmann also scope_type will not be enforced until it is explicitly set True by enforce_scope. enforce_scope default is false as of now.
17:08:46 mnaser but if its not enforced then could that not introduce other eissues?
17:09:45 eandersson Morning
17:09:56 mnaser role:reader and system_scope:system without it enforced means role:reader can get hypervisor list?
17:10:05 eandersson What is the difference from disk_gb and disk_available_least?
17:11:03 lbragstad mnaser that's why we write the policy like "(role:reader and system_scope:all) or role:admin_or_owner"
17:11:08 gmann no, as lbragstad mentioned we will add a special case of scope_type for that what keystone did - role:reader and system_scope:all
17:11:29 mnaser ok so we would have a policy enforcing both .. until we decide to cut it off
17:11:38 gmann true
17:11:39 mnaser so maybe a train could be a transitionary release i guess
17:11:43 mnaser and then we can flip the switch
17:12:10 lbragstad we need to write slightly more complicated policy check_strs to allow for the migration
17:12:18 gmann I suggest to flip in V to give 1 2 cycle of transition phase as this is huger change in policy
17:12:34 mnaser can you enable enforcement of system_scope?
17:12:36 lbragstad then we can offload more to oslo.policy using enforce_scope=True in the future and simplify the check strings
17:12:57 mnaser could a deployer enable it AND put rule:admin_or_owner set to nothing
17:13:05 mnaser and they'd be using 'the new system'
17:13:51 lbragstad yeah... if a deployer wants to opt into the new system, they just have to maintain a policy file with the *new* defaults, which omits the logical OR with oslo.policy migration

Earlier   Later