Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
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
22:51:28 mriedem and gibi ^
22:52:23 mriedem stvnoyes: i'll work on the zuulv3 job if you didn't start on that yet
22:52:54 ildikov mriedem: looks great, thanks!
22:53:08 mriedem sdague: if you're looking for an easy patch, this undumbifies our USE_NEUTRON usage in the functional tests https://review.openstack.org/#/c/529456/
22:56:58 lbragstad mgagne: we might be able to do something like - https://review.openstack.org/#/c/532685/
22:57:13 lbragstad mgagne: let me know if that helps you work around the issue
23:01:34 mgagne lbragstad: looks mostly good, commented already. I think the other issue is that Nova didn't register the legacy names and I needed to dig in code to find the expected name.
23:02:02 lbragstad mgagne: responded - yeah the deprecation bits in oslo.policy are pretty new
23:02:14 lbragstad i'm not sure if nova had a pre-existing deprecation implementation in nova
23:02:28 mgagne none that I'm aware of
23:07:29 mgagne lbragstad: ok, finally tested gist I posted above. the alias thing works fine.
23:07:49 mgagne => "compute:create": "rule:os_compute_api:servers:create"
23:08:03 lbragstad sweet
23:08:11 mgagne so legacy policy name "compute:create" becomes an alias of "os_compute_api:servers:create"
23:08:32 lbragstad nice - that makes sense
23:10:22 lbragstad mgagne: pushed a new patch
23:11:17 mgagne this works for me. only use case I'm not sure about is if both name and check string are deprecated. =)
23:11:33 mgagne like you get a new name AND a new check string :D
23:11:52 lbragstad in that case, the policy is being removed all together, right?
23:12:43 lbragstad or it can be the name and the check_str is changing at the same time...
23:12:56 mgagne I don't know tbh. but it would still be a supported use case by oslo policy, won't fail with: can't deprecate both name and check string.
23:13:10 mgagne yes, that's what I'm referring to
23:17:14 mgagne lbragstad: I'm super bad with bug description, feel free to update =) https://bugs.launchpad.net/oslo.policy/+bug/1742569

Earlier   Later