| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-10 | |||
| 19:22:55 | rybridges | but if you do it after that... I am thinking it wont update because updating would involve rewriting a file on the hypervisor | |
| 19:34:06 | melwitt | rybridges: so you're saying you want to modify the user data after it's been provided by the end user? | |
| 19:34:34 | melwitt | but it's not the end user themselves who want to update it? | |
| 19:35:03 | melwitt | it sounds like what you want is the vendor data stuff | |
| 19:41:34 | melwitt | https://docs.openstack.org/nova/latest/user/vendordata.html | |
| 19:48:49 | rybridges | eh.. not quite. That's okay. Thanks melwitt | |
| 19:52:12 | mriedem | he's looking for the server create hook | |
| 19:52:17 | mriedem | which has been deprecated forever | |
| 20:01:59 | mtreinish | mriedem: what do you want me to look at there? | |
| 20:04:16 | mriedem | mtreinish: so i've got the 3 tests in there passing, | |
| 20:04:26 | mriedem | but, that patch also has some setup stuff so it's getting large, | |
| 20:04:44 | mriedem | was thinking about changing that to just be the first test, and then put 1 patch per new test on top of that in a series | |
| 20:04:58 | mriedem | since there are a bunch of TODOs in there for more tests, i didn't want to hold that single patch for all of the tests | |
| 20:05:23 | mtreinish | mriedem: sure, that sounds like a sane way to handle it | |
| 20:05:26 | mriedem | ok | |
| 20:05:36 | mriedem | just wanted to make sure since it's going to be a bit of work | |
| 20:05:52 | mtreinish | I did quickly look at the tests the other day when you linked me to them and they seemed fine to me | |
| 20:06:22 | mtreinish | mriedem: I mean it's not that long a patch with the 3 tests in one. I'd be fine reviewing it as is too | |
| 20:06:23 | mriedem | the two patches below that one are ready to go | |
| 20:06:29 | mtreinish | it's really your call | |
| 20:06:33 | mriedem | yeah i knew you would probably, but for others | |
| 20:06:35 | mriedem | i'll split it up | |
| 20:06:43 | mriedem | plus then it will rock my tempest stats! | |
| 20:07:00 | mtreinish | heh, got to maintain your top 10 committer status :) | |
| 20:07:09 | mriedem | you know it | |
| 20:08:10 | mriedem | heh i didn't know that was still a thing http://stackalytics.com/?release=all&module=tempest&metric=commits | |
| 20:08:31 | mriedem | soon i can catch up with old man dague | |
| 20:09:30 | mtreinish | mriedem: heh, nice | |
| 20:20:48 | sdague | mriedem: yeh, well... you youngins | |
| 20:20:59 | mriedem | i can hear your fist shaking from here | |
| 20:52:50 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 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 | |