Earlier  
Posted Nick Remark
#openstack-nova - 2017-11-21
14:31:26 bauzas jianghuaw: I have multiple problems with libvirt mdevs, but that change would be okay
14:31:43 mriedem bauzas: any specific reason to use MultiStrOpt over ListOpt here? https://review.openstack.org/#/c/512580/
14:31:53 stephenfin jianghuaw, bauzas, mriedem: MultiStrOpt is deprecated, afaik
14:31:58 stephenfin Or will be soon. Don't use it
14:32:03 bauzas mriedem: I don't remember me commenting that
14:32:19 bauzas lemme verify
14:32:26 mriedem stephenfin: it doesn't say that it is https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L1571
14:32:50 bauzas hem, no, I haven't said that https://review.openstack.org/#/c/512580/1/nova/conf/vgpu.py
14:33:15 stephenfin mriedem: Hmm, odd. I was sure gcb talked about that at the PTG
14:33:22 mriedem i'm asking in -oslo
14:33:42 bauzas mriedem: stephenfin: yeah, don't see it in https://docs.openstack.org/oslo.config/latest/reference/opts.html#oslo_config.cfg.MultiStrOpt
14:33:56 bauzas if that's deprecated, then please change that
14:34:09 stephenfin I'm pretty sure gcb did talk about it, so maybe it's on his list. In any case, I wouldn't use it. It's very confusing
14:34:21 bauzas honestly, I don't see the difference
14:34:24 bauzas but meh
14:34:28 bauzas I trust you
14:34:40 bauzas if you say ListOpt should be used, then -1 the change
14:34:42 stephenfin Every other option is specified once except that special one :)
14:34:56 bauzas AFAIK, you're an oslo core :p
14:35:13 stephenfin Heh, I hate -1ing for that kind of stuff, but ok
14:35:30 openstackgerrit Surya Seetharaman proposed openstack/nova master: cleanup mapping/reqspec after archive instance https://review.openstack.org/515034
14:36:04 jianghuaw bauzas, stephenfin, mriedem: Got it. So will proceed to change it from MultiStrOpt to ListOpts. Thanks.
14:36:10 bauzas ++
14:36:21 bauzas I'll need to rebase my change, but meh
14:36:32 stephenfin ++ as commented, those things are hard to change after the fact
14:36:37 bauzas jianghuaw: just ping me when it's uploaded so I can rebase my series
14:36:49 stephenfin bauzas: I'm a pbr core - not oslo (yet ;))
14:36:50 jianghuaw bauzas, Sure.
14:37:03 bauzas stephenfin: WAT?
14:37:03 bauzas :p
14:37:10 stephenfin Probably for the better 🙈
14:37:48 bauzas ralonsoh: FWIW, working on a new release for os-traits
14:38:30 ralonsoh bauzas: thank you very much
14:46:42 openstackgerrit Jianghua Wang proposed openstack/nova master: vgpu: add enabled white list https://review.openstack.org/512580
14:46:43 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: get vGPU stats from hypervisor https://review.openstack.org/512965
14:46:43 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: provide vGPU inventory in compute node https://review.openstack.org/516217
14:46:44 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899
14:46:44 openstackgerrit Jianghua Wang proposed openstack/nova master: XenAPI: restrict to only enable one vGPU type https://review.openstack.org/521769
14:46:58 jianghuaw bauzas, ^
14:48:01 openstackgerrit Stephen Finucane proposed openstack/nova master: Add CPUWeigher https://review.openstack.org/379525
14:48:37 bauzas jianghuaw: roger, will rebase
14:49:06 jianghuaw bauzas, cool.
14:49:25 moshele stephenfin: hi can you review https://review.openstack.org/#/c/519066/ ?
14:49:40 stephenfin moshele: Big backlog today, but it's on the list :)
14:50:17 moshele stephenfin: so tomorrow :)
14:50:38 stephenfin Depends on how quickly I work through the backlog, heh
14:50:56 moshele stephenfin: :)
14:51:03 openstackgerrit Balazs Gibizer proposed openstack/nova stable/pike: Document the real behavior of notify_on_state_change https://review.openstack.org/521870
14:51:52 openstackgerrit Dan Smith proposed openstack/nova master: Alternate fix for validating image on rebuild https://review.openstack.org/521186
14:51:53 openstackgerrit Dan Smith proposed openstack/nova master: Add regression test for rebuild with new image doubling allocations https://review.openstack.org/521153
14:51:53 openstackgerrit Dan Smith proposed openstack/nova master: Fix doubling allocations on rebuild https://review.openstack.org/521662
14:52:15 dansmith mriedem: you wanna write the reno for ^? I'm struggling to formulate english sentences at the moment
14:52:22 bauzas mriedem: ralonsoh: stephenfin: https://review.openstack.org/#/c/521869/
14:52:34 bauzas mriedem: need your lovely +1
14:53:01 mriedem dansmith: sure
14:53:26 stephenfin bauzas: Do we want to merge the requirements updates first
14:53:30 stephenfin ?
14:53:30 stephenfin https://review.openstack.org/#/q/project:openstack/os-traits+status:open
14:53:44 stephenfin The rest are WIP
14:53:46 bauzas stephenfin: I looked at those
14:53:53 openstackgerrit Balazs Gibizer proposed openstack/nova stable/ocata: Document the real behavior of notify_on_state_change https://review.openstack.org/521871
14:54:03 bauzas stephenfin: and honestly, I don't see why we need to block a new release because of those
14:54:14 stephenfin Sweet. Then you have your +1
14:54:25 bauzas stephenfin: most of cores will be on vacations by the next days
14:54:51 bauzas so if we wanna merge a new release and modify g-r, then it needs to be soon
14:56:04 bauzas mriedem: FWIW, I'm not sure we need to bump g-r given nova reqs.txt is os-traits>=0.3.2 # Apache-2.0
14:56:08 bauzas you okay with that ?
14:56:25 bauzas or do you think it would be better to just amend g-r ?
14:56:52 mriedem if we're doing a release for new code in os-traits to use in nova, then we need to bump the minimum required version in g-r
14:57:06 stephenfin bauzas: What he said. If someone's on 0.3.2, it would break
14:57:18 bauzas k
14:57:24 bauzas I'll provide a new g-r then
14:58:03 stephenfin While we're here, these two should probably go in at some point too (or be abandoned) https://review.openstack.org/#/q/project:openstack/os-traits+status:open+branch:stable/pike
15:00:23 bauzas that's correct
15:00:35 openstackgerrit Eric Fried proposed openstack/nova master: WIP: placement: GET /RPs with aggs, inventories, traits https://review.openstack.org/521875
15:00:45 mriedem bauzas: -1
15:00:58 efried jaypipes cdent ^ Along the lines of what we discussed briefly yesterday.
15:01:04 bauzas mriedem: oh man, good point
15:01:16 bauzas mriedem: It's just a long day that I haven't provided a new release
15:01:20 bauzas meh
15:01:25 jaypipes efried: k. it's gonna be low priority though :)
15:01:25 mriedem psh
15:01:28 mriedem excuses excuses
15:01:52 cdent efried: noted
15:02:05 bauzas mriedem: no excuses, I'm a d-bag, that's it
15:02:21 stephenfin bauzas: Well we didn't want to say anything, but...
15:02:53 efried cdent jaypipes Would I be correct in assuming that we get a significant performance improvement by reducing the number of placement API calls, assuming everything else (amount of db work, etc.) remains the same?
15:03:14 bauzas there, fixed
15:03:19 jaypipes efried: for the nova-computes running Ironic virt driver, yeah.
15:03:41 jaypipes efried: for the KVM ones, probably won't notice much of a difference.
15:03:42 cdent efried: performance _where_ ?
15:04:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: Transform missing delete notifications https://review.openstack.org/410297
15:04:42 efried jaypipes cdent I'm talking about just placement calls. The above change set allows us to reduce 3N+1 calls down to one, to get the same data. (N is the number of providers in the tree.)
15:04:46 openstackgerrit Balazs Gibizer proposed openstack/nova master: Send soft_delete from context manager https://review.openstack.org/476459
15:05:18 efried jaypipes cdent The data as a whole is identical, the work being done on the placement side is identical, etc. - just being done in one API call instead of many.
15:05:30 cdent efried: you’re limiting the opportunities for the placement service to parallize across multiple instances of placement itself, which may or may not be a concern. I tend to prefer lots of smaller calls on many servers
15:05:39 jaypipes efried: understood. and what I'm saying is that N is not a large number for KVM. For Ironic (and maybe powervm) N can be a large number.
15:05:49 openstackgerrit Merged openstack/os-traits master: Update the documentation urls https://review.openstack.org/501122
15:06:16 efried jaypipes Ah, I understand. Nevertheless, even for a one-node tree, it would be taking 4 calls down to 1.
15:06:29 jaypipes efried: understood. :)

Earlier   Later