| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-10 | |||
| 21:50:50 | stvnoyes | all manual for now I presume? | |
| 21:50:58 | mriedem | stvnoyes: sure, until we write tempest patches | |
| 21:51:18 | mriedem | stvnoyes: if you want to add a resize test on top of the tempest patch https://review.openstack.org/#/c/266605/ go ahead | |
| 21:51:20 | mriedem | should be pretty simple | |
| 21:51:36 | stvnoyes | kk I'll do that | |
| 21:51:41 | mriedem | swap volume gets tricky b/c that's an admin-only operation so i think that has to live in a different tree structure in tempest | |
| 21:51:50 | mriedem | tempest/api/compute/admin/ | |
| 21:52:19 | mriedem | would live in here somewhere https://github.com/openstack/tempest/blob/master/tempest/api/compute/admin/test_volume_swap.py | |
| 21:52:26 | mriedem | new test class to use the new microversion | |
| 21:56:15 | mriedem | mgagne: not sure, lbragstad might know | |
| 21:56:20 | mriedem | lbragstad: "when deprecating a rule name in oslo.policy, will the generator create an alias for the old name? My concern is with Horizon which might/will still use the legacy name until updated." | |
| 22:00:59 | lbragstad | mriedem: mgagne yeah - oslo.policy supports that case | |
| 22:01:04 | lbragstad | mriedem: mgagne https://github.com/openstack/oslo.policy/blob/master/oslo_policy/policy.py#L590-L609 | |
| 22:01:26 | lbragstad | it takes the new policy and adds an OrCheck to it with the deprecated one | |
| 22:01:37 | mgagne | lbragstad: this is about the check string, not the rule name | |
| 22:01:43 | mgagne | no? | |
| 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 | |