Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
21:47:02 mriedem or...devstack
21:47:15 mordred mriedem: it's perfectly acceptable to make a nova-devstack-multiattach in the nova repo and then have cinder, devstack, tempest repos add it to their .zuul.yaml files
21:47:29 mriedem yeah i guess we'll just start with it in nova
21:47:32 mordred or it could totally go in devstack, or tempest :)
21:47:42 mriedem since the only tests so far are compute api tests in tempest
21:48:07 mriedem ildikov: stvnoyes: if one of you do start on that, the first nova patch for zuulv3 layout is https://review.openstack.org/#/c/514309/ so you'd likely build on that
21:48:13 stvnoyes mriedem ildikov: as for the CI job, I can take a look. I haven't played around with CI jobs before, but I can see how far I get
21:48:23 stvnoyes ok I'll take a look at that
21:48:26 mriedem stvnoyes: it's mostly copy and tweak
21:48:53 mriedem we just need it to set this devstack variable https://review.openstack.org/#/c/531386/7/stackrc
21:48:57 mgagne mriedem: 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.
21:49:20 mordred mriedem: this could be your first nova zuulv3-native job :)
21:49:23 mriedem like https://review.openstack.org/#/c/514309/10/playbooks/legacy/nova-lvm/run.yaml@33
21:49:27 stvnoyes mriedem: kk, btw, is there any specific test you'd like to see with libvirt 3.10? So far, attach & detach are working ok. Was their a particular scenario that was failing?
21:49:29 mriedem mordred: that i did?
21:50:04 mriedem stvnoyes: the tempest patch is testing attach/detach to 2 servers, boot from volume with 1 server, and boot from volume and snapshot that volume-backed server
21:50:23 ildikov stvnoyes: thanks much!
21:50:27 mriedem stvnoyes: i think we also need testing for resize/cold migrate and swap volume
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

Earlier   Later