| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-10 | |||
| 20:53:12 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216 | |
| 20:53:46 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 20:57:20 | mriedem | this was added in 2014: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1022 | |
| 20:57:26 | mriedem | seems it might be time to remove the get() | |
| 20:57:47 | mriedem | since the dfeault in cinder for new volumes is bootable=False | |
| 21:04:31 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: create vGPU for instance https://review.openstack.org/528832 | |
| 21:04:32 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt : Force a specificly static UUID for a mediated device https://review.openstack.org/531752 | |
| 21:04:32 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: libvirt: Use only existing mdevs if kernel race https://review.openstack.org/531853 | |
| 21:04:54 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 21:39:03 | mriedem | ildikov: on the multiattach api patch, i've got the rest api controller tests done, added a happy path functoinal test for boot from volume and attach to an existing server, and now working on negative tests for the error conditions in the API code - that should wrap it up | |
| 21:39:31 | mriedem | then ill split up the tempest test patch tomorrow probably | |
| 21:40:09 | ildikov | mriedem: ack | |
| 21:40:33 | ildikov | mriedem: is there anything stvnoyes or me should/could do? | |
| 21:41:33 | mriedem | yeah, something on my todo list is we're going to need a CI job defined for multiattach, probably in the nova experimental queue | |
| 21:41:39 | mriedem | based on the devstack patches i have | |
| 21:41:40 | mriedem | https://review.openstack.org/#/c/531386/ | |
| 21:42:20 | mriedem | i'm not sure if that job definition should live in nova with zuulv3, or if it should live in openstack-zuul-jobs since we'd want to run it on nova/cinder/tempest/devstack patches | |
| 21:42:32 | mriedem | mordred: ^ is there guidance on where a job should live if it's going to be run by multiple projects? | |
| 21:43:20 | ildikov | mriedem: ok | |
| 21:43:22 | stvnoyes | mriedem: i am testing multiattach on libvirt 3.10.. so far it's working ok. But I just noticed that one of the libvirt modules, libvirt-bin, is at 3.6. The Debian site says "This is a transitional package." Do you think it matters? | |
| 21:44:00 | stvnoyes | I'm having trouble finding a 3.10 version of that. | |
| 21:44:02 | mriedem | i don't know what a transitional package is | |
| 21:44:08 | mriedem | would probably have to ask zigo | |
| 21:45:13 | ildikov | stvnoyes: do you have bandwidth to look into the CI job too? | |
| 21:45:36 | mordred | mriedem: in general the idea is to have it live as close to the people who would be the most natural 'owners' | |
| 21:46:01 | stvnoyes | I left out the import note that followed - "This is a transitional package. You can safely remove it." That's why I was thinking it might not matter. | |
| 21:46:55 | mriedem | mordred: hmm, ok, i guess that is probably nova... | |
| 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%%' | |