Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
22:01:53 lbragstad yes - for the check string
22:01:57 lbragstad not the name
22:02:03 mgagne ok, I'm asking about name
22:02:08 lbragstad sorry - misread the question
22:02:15 mgagne because I got caught with Horizon still reading legacy name
22:02:42 mgagne I used oslo policy generator to get a policy file and used that in horizon, big mistake
22:04:23 mgagne so now what I'm trying to do is create a mapping file (still testing atm): https://gist.github.com/mgagne/c98982290ed72aecf668e5291b5ee027
22:04:37 lbragstad mgagne: so you're interested in this case - https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L1143-L1160
22:05:49 lbragstad hmm - we might have some work todo there
22:07:28 mgagne ok so there is nothing in place for that, legacy v2 got replaced by v2.1 (with new policy names) but never got some form of deprecation period or mapping
22:07:29 lbragstad mgagne: today we iterate through all the policies, but the rule is only registered with the non-deprecated name https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L627
22:08:52 mgagne I think that if a policy name is deprecated and replaced by something else, sample file shouldn't include the literal string check in the legacy one but an alias to the new policy name so you can update the check string once
22:08:55 lbragstad i suppose we could register another entry in that process with the deprecated name and check string iff that policy is deprecated
22:09:08 mgagne basically, what I'm trying to test above
22:09:39 lbragstad this is only the case when the policy *name* is changing, right?
22:09:47 mgagne yes
22:10:33 mgagne I'm sure there is more use cases but that's the one that seems to not be handled right now
22:11:00 mgagne and which is causing some issues with horizon which expects to find the legacy names (well, the version of horizon I'm using)
22:11:16 lbragstad this is because horizon uses the policy file to customize UI
22:11:33 mgagne (ocata)
22:12:24 mgagne if I generate a sample file for Nova, update it to fit my needs and then use it for Nova, Horizon will mostly read the "default" rule because it can't find the "legacy rules"
22:12:50 mgagne and default is not included anymore iirc
22:12:58 mgagne will have to double check on that one
22:13:14 lbragstad wouldn't the problem be that horizon is looking for a policy name that no longer exists?
22:13:17 mgagne yep, no default
22:13:22 lbragstad so wouldn't you need an entry for each?
22:13:27 lbragstad the deprecate option and the new option?
22:13:31 mlavalle mriedem: have you seen the way the substring query is done in https://review.openstack.org/#/c/521683/?
22:13:38 lbragstad in the generated policy file?
22:13:41 mlavalle I want to make sure you are happy with it
22:13:52 mgagne sure but... this also means you need to install the same version as Nova? can't install Horizon Ocata with Nova Newton?
22:14:02 mgagne lbragstad: yes
22:14:12 mgagne that's what I will end up with
22:14:28 mgagne because I need to satisfy Horizon
22:14:46 lbragstad so you'd need an ocata nova policy file... right?
22:17:59 mriedem mlavalle: hmm,
22:18:01 mgagne Current use case: Nova Newton with Horizon Ocata. Horizon Ocata still expects legacy policy names while generated policy file by Nova Newton does not content legacy names.
22:18:02 mriedem '%s%%'
22:18:10 mriedem mlavalle: not sure why it's not just '%%%s%%'
22:18:20 mriedem so the substring could be anywhere within the IP address
22:19:25 mgagne lbragstad: even if I had ocata policy file, it will never content legacy names ever again, they got removed and no mapping was created, even in-code.
22:19:29 mriedem mlavalle: like this http://git.openstack.org/cgit/openstack/nova/tree/nova/db/sqlalchemy/api.py#n709
22:20:13 lbragstad mgagne: well - one thing we could do is emit deprecated policies if we detect one
22:20:24 mgagne lbragstad: this also means that even if Horizon got updated, in future, you would need to update Horizon and Nova in lockstep which I suspect is something we don't want to encourage or promote
22:20:36 mlavalle mriedem: exactly. I want to make sure we deliver what you need on the Nova side. Thanks!
22:21:35 mriedem hongbin: ^
22:21:51 lbragstad mgagne: ok - let's say we're doing this https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L1143-L1160
22:22:06 lbragstad renaming foo:post_bar to foo:create_bar
22:22:09 hongbin o/
22:22:23 mriedem hongbin: see the questions about the IP substring filtering in neutron
22:22:41 mgagne lbragstad: if you end up with: "foo:post_bar": "rule:foo:create_bar", that would be great I guess
22:23:34 lbragstad or if you have "foo:post_bar": "role:fizz" and "foo:create_bar": "role"fizz"
22:23:44 lbragstad even though they are the same thing
22:23:52 mgagne lbragstad: so I need to update 2 rules if I change a check string?
22:24:09 lbragstad ah - right, i see what you mean
22:24:44 mgagne but we need to determine for how long you want to support legacy names
22:24:45 hongbin mriedem: mlavalle : the patch was originally proposed to support full substring (%%%s%%), zhenyu commented on it to give preference to a right hand substring (%s%%), so i made the revision
22:25:04 lbragstad mgagne: i think that would depend in how long you want to support a deprecated policy
22:25:20 lbragstad when it is removed, it's no longer rendered in the policy file
22:25:31 mgagne because do you want to be able to run Horizon on release Xylophone but with Nova Mitaka?
22:25:35 mriedem hongbin: hmm, ok we should ask Kevin_Zheng then probably
22:25:44 mriedem when he's awake
22:25:50 lbragstad mgagne: that's a good question - but i'm not sure i'm qualified to answer it :)
22:25:59 mgagne yea, just something to consider
22:26:04 hongbin mriedem: sure, i will send the email
22:26:10 mgagne but the one major release deprecation period might not be enough in that case
22:26:11 lbragstad would you expect to run deprecated configuration options from Mitaka in Xylophone/
22:26:16 mgagne because the*
22:26:32 mgagne current, that's what I'm doing
22:26:51 mgagne was Nova Kilo with Horizon Ocata until very recently.
22:27:00 mgagne now Mitaka/Ocata
22:27:05 lbragstad ack
22:27:22 mgagne but also... Horizon should use new names...
22:27:45 lbragstad right - i also expect this issue to be limited to horizon feeding off a generated policy file
22:28:29 mgagne lbragstad: afaik, there is no way to consume policy through API so there might be some 3rd party softwares consuming policy files too
22:28:30 bauzas any idea why it sticks my oslo.policy version to be 1.28.1 while I'm upgrading the package before ?
22:28:31 lbragstad because if nova deprecates a policy name, they are likely going to start using the new policy name in the service around the same time they deprecate it
22:28:58 bauzas because it raises an exception when running nova api_db sync
22:29:03 mgagne lbragstad: would need to find a way to detect legacy policy names usage in horizon
22:29:03 mlavalle hongbin, mriedem: thanks!
22:29:04 lbragstad mgagne: yeah
22:29:48 mgagne lbragstad: policy names got updated in Horizon Pike
22:29:53 mgagne https://github.com/openstack/horizon/commit/c61ae4f0834253e523c4443cecb3ce5eb06bf89b
22:30:18 mgagne but issue still remain, can't update a policy name without breaking horizon
22:31:04 lbragstad this is neither here nor there, but i'm hoping to have a PoC of a capabilities API that removes the need for rendered policy files by dublin
22:32:02 bauzas oh snap, I need to git pull my requirements directotyu
22:33:06 lbragstad mgagne: would you want to open a bug against oslo.policy for this?
22:33:22 mgagne lbragstad: project is using LP?
22:33:27 lbragstad yes
22:33:30 mgagne cool cool
22:33:35 mgagne will do
22:33:58 lbragstad https://launchpad.net/oslo.policy
22:34:11 mgagne sure, just wanted to make sure it's not storyboard =)
22:34:47 lbragstad fwiw - i think we should be able to support rendering deprecated policy names pretty easy
22:35:20 lbragstad but getting horizon to figure out if a policy name is deprecated is going to require a bit more work
22:47:28 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512
22:48:59 openstackgerrit Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216
22:50:50 openstackgerrit Matt Riedemann proposed openstack/nova master: [api] Allow multi-attach in compute api https://review.openstack.org/271047
22:51:05 mriedem ildikov: johnthetubaguy: stvnoyes: ^ done with the API change, ready for review
22:51:07 mriedem tests are done

Earlier   Later