Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-04-27
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
16:20:13 gmann I am not sure, we have. but lbragstad or bnemec can point to if there is any.
16:21:09 gmann i meant explicitly saying, 'this way of re-genrating policy file or having not-override rule in policy file etc etc can break you if you do not carefully audit on upgrades'
16:27:47 openstackgerrit Takashi Natsume proposed openstack/nova master: Fix list rendering in the accelerator support doc https://review.opendev.org/721846
16:28:00 lbragstad gmann we have this
16:28:02 lbragstad https://bugs.launchpad.net/oslo.policy/+bug/1853170
16:28:02 openstack Launchpad bug 1853170 in oslo.policy "Need documentation on recommended operator workflow for deprecated policies" [High,Triaged]
16:28:02 openstackgerrit Takashi Natsume proposed openstack/nova master: Update contributor guide for Victoria https://review.opendev.org/722647
16:30:05 lbragstad gmann i don't think there is anything in review for that, yes
16:30:07 lbragstad yet*
16:32:06 gmann lbragstad: i see, thanks
16:32:33 stephenfin melwitt: confident enough to bump your +1 to +2 now? https://review.opendev.org/#/c/720725/
16:35:47 gibi gmann: I have to stop for today. If you start writing a reno update for the policy thing then please link it to me and I will read it first thing in the morning
16:37:16 gmann gibi: ok, I will update the upgrade section for now to mention the re-generated policy file case. and later we can work on some generic doc (bug/1853170).
16:37:44 gibi gmann: ack, thanks
17:43:53 sean-k-mooney stephenfin: can you take a look at https://review.opendev.org/#/c/722407/
17:44:02 sean-k-mooney stephenfin: it needt to merge before your change can merge
17:48:58 AJaeger any nova core available for two tiny cleanups related to Babel/translations, please? https://review.opendev.org/#/c/723206/2 and https://review.opendev.org/#/c/720725/1 ?
18:01:28 openstackgerrit Merged openstack/python-novaclient master: Use unittest.mock instead of third party mock https://review.opendev.org/723152
18:19:56 openstackgerrit Merged openstack/nova master: Add placeholder migrations for Ussuri backports https://review.opendev.org/722546
18:51:11 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645
18:51:41 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Clarify the policy new defaults upgrade notes https://review.opendev.org/723645

Earlier   Later