| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-04-27 | |||
| 15:32:49 | gmann | later is kind of argument that people rely on 'no deprecated rule' in generated file to end up over permission and leak API | |
| 15:33:04 | zigo | stephenfin: This leaves us with "generate policy.json and nova.conf that are maching and working together by default" indeed ! | |
| 15:33:08 | gmann | so we may fix one upgrade but break other | |
| 15:35:13 | zigo | If I had such an option as "oslopolicy-sample-generator --use-scoped" and/or "--dont-use-scoped" then I would generate the config file twice, as a favor to Debian users, so they could see both ... | |
| 15:35:21 | openstackgerrit | Merged openstack/python-novaclient master: Remove future imports https://review.opendev.org/723153 | |
| 15:35:22 | zigo | It's probably too late in this cycle to do that, though. | |
| 15:36:40 | lbragstad | gmann isn't that the intended behavior you want? | |
| 15:38:04 | gmann | lbragstad: yeah, that is intended as per me :) but problem is for upgrade used to re-generated the fresh file and still think default works is broken | |
| 15:38:25 | gmann | zigo: we can do but still user need to change their script to add new option to that tool '--dont-use-scoped' or other. | |
| 15:38:36 | dansmith | gmann: lbragstad: to avoid me having to google.. what is the different thing that users have to do to get a scoped token? | |
| 15:39:29 | lbragstad | the request to keystone to get a token changes a bit, but users can invoke that with clients by setting a different property in their cloud config | |
| 15:40:10 | dansmith | okay so their openrc or clouds.yaml (or whatever) has to change | |
| 15:40:15 | lbragstad | yes | |
| 15:40:37 | dansmith | and are those two things getting generated as scoped by default nowadays? | |
| 15:41:03 | dansmith | or can you not ask for scoped until something else changes? | |
| 15:41:28 | lbragstad | i guess it depends on what generates those files | |
| 15:41:49 | lbragstad | you're asking if openrc or clouds.yaml is generated with project-scope by default? | |
| 15:43:55 | dansmith | lbragstad: yeah, like.. has everyone since stein (as an example) been getting scoped tokens and not knowing it? | |
| 15:44:06 | dansmith | just trying to figure out how impactful the move to requiring them will be | |
| 15:44:59 | lbragstad | dansmith yeah - to do anything useful, most people will need a scoped token of some form | |
| 15:45:17 | lbragstad | historically, that scope has always been project | |
| 15:45:42 | lbragstad | or - project-scope has been the standard for getting anything done, like booting a server | |
| 15:46:01 | dansmith | I'm confused | |
| 15:46:28 | dansmith | lbragstad: I thought that when we move to this new scoped policy that users need to be getting scoped tokens that they likely haven't been getting in the past? | |
| 15:46:41 | dansmith | which is why zigo's token immediately stopped working and launched us into this discussion | |
| 15:46:42 | lbragstad | dansmith sorry - let me back up | |
| 15:47:08 | lbragstad | keystone has supported scoped tokens for a long time - uses have always been able to get a scoped token | |
| 15:47:20 | lbragstad | in the past, that token has always been scoped to a project | |
| 15:47:22 | dansmith | sure, I get that | |
| 15:47:30 | lbragstad | the new system is using a different scope target | |
| 15:47:54 | lbragstad | and some APIs are going to require that new target, instead of a project-scoped tokne | |
| 15:48:12 | lbragstad | which is why zigo's old token (which i'm assuming is project-scoped) stopped workin | |
| 15:48:15 | lbragstad | working* | |
| 15:48:33 | zigo | If we require everyone to change something in their openrc, it *will* break a lot of user who wont understand. | |
| 15:48:33 | zigo | Maybe that's needed, I don't even understand what this scope thingy is for, but just warning everyone here. | |
| 15:48:33 | zigo | At least, if we're moving to that direction, then we must have some kind of correct error message output in the clients. | |
| 15:48:34 | gmann | but 'system' scope is not default user has to explicit request that | |
| 15:49:18 | dansmith | I'm trying to figure out if realistically everyone is going to need to change their openrc, or only people who got their openrc from horizon before some release, or ... | |
| 15:49:34 | dansmith | I know openrc can come from various places, but trying to figure out the "scope" of the impact | |
| 15:49:43 | dansmith | does devstack generate scope-having openrcs? | |
| 15:49:55 | lbragstad | yes | |
| 15:50:09 | zigo | lbragstad: What does it look like? | |
| 15:50:15 | zigo | export OS_SCOPE= ? | |
| 15:50:16 | lbragstad | it does it with clouds.yaml, actually | |
| 15:50:51 | lbragstad | https://opendev.org/openstack/devstack/src/branch/master/tools/update_clouds_yaml.py#L56 | |
| 15:51:04 | lbragstad | export OS_SYSTEM_SCOPE=all | |
| 15:51:30 | lbragstad | that's going to tell keystone to give you a system-scoped token instead of a project-scoped token | |
| 15:51:52 | zigo | lbragstad: So, that's to be added to the admin openrc ? | |
| 15:52:02 | dansmith | but most users want a project scoped token right? | |
| 15:52:05 | lbragstad | to get back to your impact question - changes to openrc are primarly admin related | |
| 15:52:08 | lbragstad | dansmith yes | |
| 15:52:22 | dansmith | lbragstad: ah, okay so admins need to tweak their openrc bug regular users will not? | |
| 15:52:33 | lbragstad | people who aren't accessing system-level APIs shouldn't need to set this new value and get system-scoped tokens | |
| 15:52:44 | gmann | true. otherwise it might be over permission issue for rule changed from admin->system-reader etc | |
| 15:53:01 | lbragstad | yes - for the most part | |
| 15:53:36 | dansmith | okay that wasn't clear to me before, so that's good news | |
| 15:53:44 | dansmith | zigo: I guess you were using an admin user? | |
| 15:54:07 | zigo | dansmith: not only myself, but puppet-openstack too, yeah ! | |
| 15:54:09 | openstackgerrit | Merged openstack/nova stable/ussuri: Update .gitreview for stable/ussuri https://review.opendev.org/722518 | |
| 15:54:15 | openstackgerrit | Merged openstack/nova stable/ussuri: Update TOX_CONSTRAINTS_FILE for stable/ussuri https://review.opendev.org/722520 | |
| 15:54:38 | zigo | dansmith: What first started breaking was puppet-octavia that couldn't create the Octavia flavor. | |
| 15:54:39 | dansmith | okay | |
| 15:54:54 | zigo | Then I tried as the admin user, and didn't understand what was going on... | |
| 15:55:13 | lbragstad | fwiw - we describe the concept and motivation behind all the scopes here - https://docs.openstack.org/keystone/latest/contributor/services.html#authorization-scopes | |
| 15:55:29 | zigo | lbragstad: Thanks, I'll read it all. | |
| 15:56:05 | dansmith | lbragstad: yeah I read that and I get it, | |
| 15:56:15 | dansmith | I thought there would still be a change to the user mechanics though | |
| 15:56:28 | dansmith | but likely because most of our discussions focus on our usage, which is generally admin | |
| 15:57:07 | lbragstad | dansmith unfortunately, because policy is completely configuration based, there could be deployments where this gets messy because the deployer wanted to let end users list hypervisors (or something weird like that) | |
| 15:58:06 | dansmith | yeah, so those users will need to learn something different now right? | |
| 15:58:23 | dansmith | does that mean they've lost (or will lose) the ability to list hypervisors and their instances with a single token? | |
| 15:58:59 | lbragstad | possibly - but it depends on how the deployer setup their custom policy | |
| 15:59:04 | dansmith | because I can imagine that sucking for scripts | |
| 15:59:13 | lbragstad | yeah - i completely agree | |
| 15:59:25 | gmann | yeah if both policy are override for same permission then they keep working | |
| 16:00:03 | gmann | if mix like one override and one was relying on default, now re-generated file will mesh up the single token | |
| 16:02:16 | lbragstad | zigo i typically put system users behind a different cloud profile, so i set system_scope: all in my clouds.yaml under a different name | |
| 16:02:50 | lbragstad | then i use --os-cloud system-admin or --os-cloud project-user (or whatever) | |
| 16:03:26 | lbragstad | ymmv - but if found that useful in the past when managing different scopes | |
| 16:03:32 | lbragstad | i found* | |
| 16:03:58 | dansmith | problem is, kinda, that we're enforcing our view on what is system-level information now in a way that they can't override | |
| 16:04:16 | dansmith | for single-tenant clouds, that just introduces unnecessary overhead for a distinction they don't care about | |
| 16:08:55 | gmann | when we enable scope by default at some point they anyways have to change their tokens. | |
| 16:09:30 | lbragstad | dansmith yeah - that's true | |
| 16:09:41 | dansmith | what I mean is, the scope-based system introduces complexity | |
| 16:09:43 | gmann | for single-tenant clouds, it might be weird | |
| 16:12:57 | zigo | GOT MY FIRST INSTANCE ON USSURI UP AND RUNNING !!! \o/ | |
| 16:13:09 | gibi | back | |
| 16:13:16 | gmann | anyways 're-generate fresh policy file' case for me is 'they want the new default-only always' and if old things stop working that need audit carefully from release notes or warnings. | |
| 16:13:19 | lbragstad | they'll need to be aware of the context they're operating on | |
| 16:14:50 | gibi | gmann, dansmith: do I understand correctly that we need at least a release notes update to document what zigo has found? What else we need to / can do in Ussuri? | |
| 16:14:53 | gmann | like uncap 'hacking' version in our requirement file which mean 'we will adopt the new changes always and if broken we fix our code' | |
| 16:15:39 | sean-k-mooney | gmann: well hacking is used by multiple project but not all projects will want to use the same checks | |
| 16:16:05 | sean-k-mooney | nova and neuton have completely different approchs to self.assert* methods | |
| 16:16:13 | gmann | sean-k-mooney: true, that is why many projects cap it | |
| 16:16:27 | sean-k-mooney | neutron blocked the use of any not in py27 and nova used mock the lib | |
| 16:18:03 | gmann | gibi: dansmith lbragstad in addition to release note for nova ussuri, should we have a clear doc from oslo/keystone or somewhere generic on 'how to generate and use policy file and how deployer can be broken for xyz cases'. i mean a single recommended way instead of supporting all possible way deployment doing ? | |
| 16:19:15 | sean-k-mooney | gmann: well that would be in oslo.policy correct | |
| 16:19:22 | sean-k-mooney | or rather should be | |
| 16:19:41 | sean-k-mooney | e.g. discribing how the lib should be used by developers | |