Earlier  
Posted Nick Remark
#openstack-nova - 2018-05-30
13:59:20 jichen dansmith: and could you please check this -2 on https://review.openstack.org/#/c/523387/ ? it's been reviewed by some core and non-cores, will there be some criteria to remove the -2 so I can get more core to help (efried has reviewed the patch and it's dependency patches previously thoroughly)
14:00:09 dansmith jichen: that -2 is just to hold the base patch until that patch and the rest have +2+W on them so we don't land a driver with no function
14:00:25 dansmith jichen: so yes, I'll drop that procedural -2 when the approvals are stacked up behind it
14:00:48 dansmith I said that on the patch, so it shouldn't be preventing anyone from reviewing it
14:00:53 jichen dansmith: ok, I will get more people to review and have +2 +w on them then ping you later, thanks a lot
14:00:57 dansmith yep
14:05:12 mriedem sahid: some comments in your neutron docs patch for trusted vf https://review.openstack.org/#/c/571167/
14:06:38 mriedem dansmith: just noticed this https://review.openstack.org/#/c/570685/ above, but wasn't there something similar that bnemec did for tripleo?
14:07:11 dansmith I think he proposed something
14:08:34 bhagyashris kashyap: any idea about ^
14:09:52 kashyap bhagyashris: Sorry, which one?
14:11:15 openstackgerrit Moshe Levi proposed openstack/nova stable/pike: Don't overwrite binding-profile https://review.openstack.org/563501
14:11:55 mriedem so something that's been bothering me about the FFU sessions which i don't think anyone has brought up,
14:12:07 bhagyashris kashyap: actually i have written functional test here: https://review.openstack.org/#/c/560459/11/nova/tests/functional/test_servers.py the patch is having libvirt related changes but in the functional test case i have not initialized the actual libvirt driver
14:12:07 mriedem besides just saying, the config options churn a lot,
14:12:34 mriedem is that for the upgrade support tag, we can't drop config options within a release, but we can across boundaries,
14:12:45 mriedem which includes dropping support for deprecated config option names,
14:13:09 mriedem sometimes we leave those deprecated config option aliases around for much more than 1 release, like pci_passthrough_whitelist and the scheduler_default_filters
14:13:17 bhagyashris kashyap: so as per the review comments I am trying to initialized the actual libvirt driver so that the change in code will be tested but i am facing some issues
14:13:24 mriedem i'm kind of surprised the FFU folk haven't pushed for config option drop/renames to last more than 1 release
14:13:58 mriedem lyarwood: have you heard anything like ^ in your FFU travels?
14:14:09 kashyap bhagyashris: If you don't mind, I'm in the middle of something. This requires me to see all the context, will get to it tonight.
14:15:11 bhagyashris kashyap: ok np but i am not sure will be present because i am working in IST time zone so here it's almost EOD
14:15:27 mriedem e.g. pci_passthrough_whitelist was deprecated in ocata https://review.openstack.org/#/c/356604/ and renamed to [pci]/passthrough_whitelist, certainly that's a fair enough amount of time to drop the old deprecated name
14:15:43 kashyap bhagyashris: I'll comment on the review tomm. I need to be AFK soon
14:16:16 bhagyashris kashyap: ok thank you :)
14:18:40 lyarwood mriedem: yeah some ops/diy folks have asked for that but we (TripleO) don't need it, heat/puppet takes care of everything for us under the covers.
14:20:02 mriedem i imagine the pain is really just needing to read through the release notes to see which config options are deprecated/dropped each release
14:20:10 mriedem and digesting that across all projects per release you're FFing through
14:23:18 lyarwood mriedem: yeah, something this group is trying to address for ops/diy folks AFAIK - https://www.openstack.org/videos/sydney-2017/making-fast-forward-upgrade-openstack-possible-with-configuration-mapping-tool
14:25:18 lyarwood https://review.openstack.org/#/c/526314/ maybe?
14:31:38 mriedem yup i heard about that for the first time at the summit
14:38:45 efried bhagyashris: Looks like the libvirt library isn't a [test-]requirement. If you install it into your functional venv, you should be able to get around that import error.
14:39:08 openstackgerrit Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597
14:39:25 mriedem jaypipes: figured out massimo's cold migrate issue in the ML
14:39:34 efried bhagyashris: As for the second thing, not sure I can help without seeing the code. Can you upload your patch set?
14:41:50 bhagyashris efried: here is my second approach test case http://paste.openstack.org/show/722352/
14:42:47 bhagyashris efried: under /nova/tests/functional/libvirt/test_rt_servers.py
14:42:47 jaypipes mriedem: I saw that. :)
14:43:01 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove usage of migrateToURI{2} APIs https://review.openstack.org/567258
14:43:32 bhagyashris efried: can you help me how i should install libvirt library in my functional venv
14:43:45 efried bhagyashris: Are you still getting that import error?
14:44:58 stephenfin bhagyashris: IIRC, you need to install the libvirt and python-libvirt packages using your package manager (apt, dnf, yum...)
14:45:06 efried bhagyashris: You would do it like this:
14:45:06 efried bash # enter a new subshell
14:45:06 efried source .tox/functional/bin/activate # enter the `functional` venv
14:45:06 efried pip install libvirt # install the lib into the venv
14:45:06 efried exit # leave the venv by leaving the subshell
14:45:18 efried stephenfin: Oh, they're apt, not pip?
14:45:20 openstackgerrit Stephen Finucane proposed openstack/nova-specs master: Add 'numa-aware-vswitches' spec https://review.openstack.org/541290
14:45:32 efried bhagyashris: Listen to stephenfin, not me. He would know better.
14:46:20 stephenfin efried: I think so, yeah. It's installed by default on Fedora, anyway
14:46:29 dansmith bhagyashris: what stephenfin said
14:47:54 efried stephenfin: If you're in a helpful mood, would you take a look at bhagyashris's paste above? What we're going for here is a functional test setup that uses the actual libvirt driver as much as possible, so that the compute node RP is created in placement, and update_provider_tree gets called by the RT on compute startup and periodics.
14:48:29 mriedem all of this request spec hydration code just needs to be burned out with acid/fire; i've had a todo on my list for awhile to actually do that, but...
14:48:41 efried and I don't know from libvirt, so don't really have a concept of how/where stuff needs to be mocked or whatever.
14:48:58 stephenfin efried: I thought functional tests were supposed to use fakelibvirt everywhere?
14:49:35 stephenfin i.e. you're testing everything in nova but nothing outside it, if possible. Integration tests (Tempest) are for testing the whole system
14:49:37 efried stephenfin: You mean nova.tests.unit.virt.libvirt.fakelibvirt.FakeLibvirtFixture ?
14:49:40 stephenfin Yup
14:49:47 sahid dansmith: what was the agreement regarding incrementing objects version for os-vif?
14:49:49 stephenfin Wait, lemme double check
14:49:50 sahid https://review.openstack.org/#/c/570959/1/os_vif/objects/vif.py
14:50:40 stephenfin efried: See nova/tests/functional/libvirt/test_numa_servers.py
14:50:58 dansmith sahid: what do you mean? that patch looks correct to me (wrt the version)
14:51:08 dansmith sahid: if it's an os-vif-specific thing, then I guess ask jaypipes
14:51:46 sahid dansmith: no it's not it's really about objects verion. I think you did not want that we incrmeent the version because that is not going to be shared by rpc
14:51:50 sahid or something like that, no?
14:52:06 sahid at least it's not right now
14:52:16 openstackgerrit Elod Illes proposed openstack/nova stable/pike: placement: Fix HTTP error generation https://review.openstack.org/571218
14:52:26 mriedem i thought we tried to follow the normal object versioning in os-vif even if it's not going over the wire yet
14:52:33 dansmith sahid: but it could be serialized somewhere else at some point, like between neutron and nova
14:52:44 dansmith mriedem: right, I'm not sure why not, but maybe I'm missing something
14:53:22 sahid mriedem, dansmith ok so let's do that, seems reasonable yes
14:53:32 stephenfin mriedem, dansmith: Reworked the numa-aware-vswitch spec per our discussion in Vancouver. Lemme know if I missed anything
14:53:41 stephenfin Will start reworking the patches themselves shortly
14:53:48 bhagyashris efried, stephenfin: thanks checking for the same.
14:54:02 mriedem stephenfin: ok thanks,
14:54:08 mriedem got a couple of patches ahead of me yet
14:54:18 stephenfin ack
14:54:49 dansmith stephenfin: cool. given the complexity here, I think it probably makes sense to evaluate the spec and the code somewhat in parallel
14:55:21 stephenfin dansmith: Just to make sure, there isn't a deadline I need to wary of, in that case?
14:55:36 dansmith oh, maybe
14:55:58 stephenfin I'm also nervous of forgetting our learnings about not solving everything in the spec
14:56:17 stephenfin I think the code that I already have proves out the idea. Now I just need to shuffle about where I'm storing stuff
14:56:40 stephenfin (also, no spec = no runway slot)
15:01:00 bauzas gentle reminder for folks that the spec about multiple vGPU types has been updated https://review.openstack.org/#/c/557065/
15:01:06 bauzas jaypipes: dansmith: ^
15:02:21 mriedem stephenfin: spec freeze is june 7
15:02:25 mriedem so you've got about a week
15:02:33 stephenfin to...?
15:02:38 mriedem get the spec approved
15:03:13 stephenfin That's in your hands then, I guess? I'll work on updating the code in the interim
15:03:17 mriedem probably not a bad idea to do another spec review sprint/flush in the coming week to get anything we want into rocky through before spec freeze
15:03:34 mriedem my volume multiattach enhancement spec has been waiting too
15:04:48 bauzas mriedem: you can review this easy spec for just a conf opt https://review.openstack.org/#/c/557065/
15:05:11 mriedem i can add it to the queue
15:05:15 cfriesen mriedem: what are your thoughts on getting https://review.openstack.org/#/c/465787/ merged?
15:05:29 bauzas mriedem: fair enough
15:05:41 cfriesen mriedem: I guess you've got a todo in there still

Earlier   Later