Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-01-15
21:24:57 bauzas hop là
21:25:54 bauzas dansmith: just in case you're still around, I'm thinking about hard reboot
21:26:28 bauzas dansmith: I could just ask for the existing mdev before destroying the guest, and then pass it back to _get_guest_xml() like I said
21:27:45 bauzas dansmith: but then, that means that for example, if we have a lot of months in between stopping the instance and restarting it, then we won't verify if that's still okay
21:28:04 bauzas the reason actually why we try to retry the xml
21:28:14 bauzas and not just reusing it
21:28:31 bauzas if we agree with that, fine
21:28:41 bauzas if we don't want that, then we would need to pass again the allocation
21:28:46 bauzas thoughts ?
21:29:10 sean-k-mooney jaypipes: bauzas melwitt dansmith when ye get a chance can ye take a look at https://review.openstack.org/#/c/533766/ to unblock https://review.openstack.org/#/c/532987/
21:29:54 bauzas sean-k-mooney: easy +2
21:30:18 bauzas oh wait
21:30:36 bauzas sean-k-mooney: what is the min os-vif version for Nova ?
21:30:59 sean-k-mooney currently 1.6 i think let me check
21:31:45 sean-k-mooney 1.7.0
21:34:05 bauzas sean-k-mooney: -1 because https://github.com/openstack/os-vif/blob/1.7.0/os_vif/objects/vif.py
21:34:26 jaypipes why do we have open-ended dependencies like >=1.7.0 again? :(
21:35:08 sean-k-mooney well we have a catch 22 then
21:35:22 sean-k-mooney the change that increases the upper constriants need this change
21:36:08 sean-k-mooney jaypipes: they are closed by upper-constratints
21:36:29 bauzas sean-k-mooney: before merging the nova change, we should IMHO first bump the min version
21:36:50 bauzas sean-k-mooney: is g-r accepting >= 1.8.0 ?
21:36:59 bauzas if so, just change directly nova requirements.txt
21:37:04 bauzas in the same change
21:37:14 bauzas if not, you need first to modify g-r
21:37:51 sean-k-mooney bauzas: no g-r is os-vif>=1.7.0 u-c is os-vif===1.7.0
21:38:23 sean-k-mooney we cant increase g-r without first increaseing u-c and u-c need that patch
21:42:52 bauzas sean-k-mooney: mmm, looks like a Depends-On change then
21:43:26 sean-k-mooney the depends-on is currently from https://review.openstack.org/#/c/532987/ to https://review.openstack.org/#/c/533766/2
21:43:27 openstackgerrit Artom Lifshitz proposed openstack/nova master: Refactor _build_device_metadata https://review.openstack.org/533804
21:43:27 openstackgerrit Artom Lifshitz proposed openstack/nova master: Consider hostdev devices when building metadata https://review.openstack.org/533805
21:43:35 bauzas sean-k-mooney: I guess the gate is not accepting to upgrade upper-constraints because it tests nova ?
21:43:46 sean-k-mooney yep
21:43:48 bauzas shit
21:44:11 sean-k-mooney we could pin os-vif in nova then increase the upperconstraints then fix the test and bump minium
21:44:26 sean-k-mooney and unpin
21:45:15 bauzas sean-k-mooney: I think we can possibly ask nova to bump os-vif to 1.8.0 and in the meantime have the g-r change that bumps both global-reqs.txt and upper-constraints.txt
21:45:37 bauzas since there will be a depends-on, that should gate correctly
21:46:03 bauzas but I'm not a requirements expert
21:46:05 bauzas tonyb: around ?
21:46:30 bauzas tonyb: questions for a requirements upgrade loop
21:46:49 sean-k-mooney the change that fixes the tests for 1.8 also works on 1.7 because of weird ness with ovo hence why the patch is currently passing zuul without using os-vif 1.8.0
21:48:42 bauzas sean-k-mooney: no I think the nova change uses 1.8.0
21:48:57 bauzas sean-k-mooney: because pypi will give you the last version
21:48:57 sean-k-mooney basically https://github.com/openstack/nova/blob/6a5673a16f8329007880b67a6dbecbe62ac368d7/nova/tests/unit/network/test_os_vif_util.py#L34-L38 means that the extra datapath_type field is discarded
21:49:11 sean-k-mooney bauzas: no i checked locally it was using 1.7.0
21:49:25 sean-k-mooney let me check the test logs
21:50:05 bauzas oh fun, you're right http://logs.openstack.org/66/533766/2/check/openstack-tox-py27/45f0378/job-output.txt.gz#_2018-01-15_20_03_47_088918
21:51:00 sean-k-mooney yep so normally this would be a pain in the ass and we would have to bump the minium but in this case we dont
21:51:35 bauzas :/
21:51:48 bauzas wait
21:52:20 bauzas that works because it's using o.vo so maybe it's just downgrading the version
21:52:28 bauzas I mean the object version
21:52:38 bauzas hence why it works
21:53:38 sean-k-mooney well im adding a new filed to the expected value so use if it downgraded it would discard it but os-vif 1.7.0 does not have explcit down grade logic for 1.8.0 objects
21:54:49 sean-k-mooney bauzas: basically it works because of this https://github.com/openstack/oslo.versionedobjects/blob/1.18.0/oslo_versionedobjects/base.py#L514-L520
21:55:52 sean-k-mooney obj_to_primitive loops over the ovo fields and uses that to generate the dictionary retrunt by obj_to_primitive
21:56:02 bauzas sean-k-mooney: right, it works thanks of the ovo framework, that's it
21:56:07 bauzas soooooo...
21:56:10 sean-k-mooney since datapath_type is not in the 1.7.0 field list it just gets discared
21:56:13 bauzas what to do ?
21:56:17 bauzas I think I'll +2
21:56:26 bauzas it's harmless
21:56:40 bauzas and unblocks things
21:57:39 sean-k-mooney out side of unit tests we have defencive logic which will only populate the datapath_type if it is defined in the vif object
21:58:08 sean-k-mooney and in os-vif we also default to the original hardcoded values if the datapath_type is not set in the profile
21:58:16 sean-k-mooney so in real code this is safe
21:58:43 bauzas right
21:59:53 sean-k-mooney anyway its almost 10 so its 2 hours past when i should have gone home. catch ye tommorow o/
22:00:29 bauzas \o
22:01:02 openstackgerrit Jay Pipes proposed openstack/nova master: placement: _get_trees_matching_all() https://review.openstack.org/531512
22:01:02 openstackgerrit Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899
22:22:49 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564
22:22:50 openstackgerrit Eric Fried proposed openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539
22:22:50 openstackgerrit Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540
22:22:51 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756
22:22:51 openstackgerrit Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541
22:22:52 openstackgerrit Eric Fried proposed openstack/nova master: Scheduler[Report]Client.get_provider_tree https://review.openstack.org/521098
22:22:52 openstackgerrit Eric Fried proposed openstack/nova master: WIP: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
22:22:53 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.snapshot => ProviderSnapshot https://review.openstack.org/533244
22:22:53 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246
22:22:54 openstackgerrit Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808
22:23:41 efried jaypipes I removed that 'generation' param in the snapshot patch (where I also cleaned up the other _Provider-accessing cheats).
22:23:57 efried jaypipes If that's too messy for ya, I'll reshuffle the whole series.
22:27:06 tonyb bauzas: you need 1 review to bump u-c; a second that bumps g-r and have the nova change gate on that 2nd chnage ... which I think is basically what you said
22:34:57 bauzas tonyb: the problem is that it seems the u-c change is gated by nova which needs the test modification
22:35:04 bauzas as per sean-k-mooney
22:38:04 efried jaypipes I'm not convinced that ProviderTree.delta(other_provider_tree) is the way to go, because whatever that guy returns is going to be an ugly blob of unstructured data. I was thinking to do the diff-and-update logic in a single method either in report client or resource tracker.
23:20:42 jaypipes efried: I'd be fine with that (single method diff-and-update thing)
23:20:53 efried jaypipes coo, working on it.
23:20:56 jaypipes efried: and will re-review your bottom series tomrrow morn.
23:21:01 efried ack
23:21:06 jaypipes efried: signing off for the night.
23:21:11 efried sleep tight
23:21:16 jaypipes danke
23:25:10 openstackgerrit Chris Dent proposed openstack/nova master: WIP: Refactor WSGI apps and utils to limit imports https://review.openstack.org/533797
23:27:24 openstackgerrit Sylvain Bauza proposed openstack/nova master: WIP: libvirt: pass the mdevs when rebooting the guest https://review.openstack.org/533818
23:29:56 gmann ameeda: sure, ll check that
23:30:59 openstackgerrit Eric Fried proposed openstack/nova master: ComputeDriver.update_provider_tree() https://review.openstack.org/521187
23:30:59 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.snapshot => ProviderSnapshot https://review.openstack.org/533244

Earlier   Later