| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-21 | |||
| 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 | :p | |
| 14:37:03 | bauzas | stephenfin: WAT? | |
| 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: provide vGPU inventory in compute node https://review.openstack.org/516217 | |
| 14:46:43 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: get vGPU stats from hypervisor https://review.openstack.org/512965 | |
| 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:44 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: create vGPU for instance https://review.openstack.org/516899 | |
| 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: Fix doubling allocations on rebuild https://review.openstack.org/521662 | |
| 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: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 | https://review.openstack.org/#/q/project:openstack/os-traits+status:open | |
| 14:53:30 | stephenfin | ? | |
| 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 | mriedem | psh | |
| 15:01:25 | jaypipes | efried: k. it's gonna be low priority though :) | |
| 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 | efried | jaypipes I guess I'm asking if the overhead of the API calls is significant. | |
| 15:06:29 | jaypipes | efried: understood. :) | |
| 15:07:31 | cdent | efried: if it is possible to measure instead of speculate that would be great, but my speculation would be that http overhead is not the limiting factor in the big picture in these situations | |
| 15:08:05 | cdent | certainly as a micro optimization, at webscale™, http request overhead matters | |
| 15:08:25 | efried | cdent Okay, interesting. Well, if for no other reason than it makes the client code easier... | |
| 15:08:32 | cdent | but only if it cannot be ameliorated by parallelization | |
| 15:09:30 | cdent | my gut reaction is that your prematurely optimizing, and that your efforts would be better served by trying to break stuff | |
| 15:09:41 | cdent | so that when we fix stuff, we’re fixing the right stuff | |
| 15:09:55 | cdent | but I’m sure telling grandma how to suck eggs | |
| 15:10:12 | cdent | efried: Are you familiar with that phrase? I didn’t know it when I first heard it and it totally confused me. | |
| 15:10:39 | efried | cdent No, but google helped me out. | |
| 15:10:58 | efried | cdent In the context of the SchedulerReportClient, parallelization would entail some nontrivial rework, likely including spawing extra threads, which doesn't seem likely. | |
| 15:11:26 | cdent | no, I mean parallization at the global level, not the per “query” level | |