Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-10
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: WIP: libvirt: Use only existing mdevs if kernel race https://review.openstack.org/531853
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: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)

Earlier   Later