| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-23 | |||
| 10:51:57 | kashyap | dansmith: melwitt: While I understand the backport stance. FWIW, talking to danpb (who is SME on this topic) on IRC, he still thinks it's an artificial limiting for the sake of backports. | |
| 10:52:27 | kashyap | I feel that we're over-evaluating. But whatever. | |
| 11:04:03 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova-specs master: Complex (Anti)-Affinity Policies https://review.openstack.org/546925 | |
| 11:06:11 | openstackgerrit | sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522 | |
| 11:47:19 | sahid | jaypipes: i think we are good with the trusted vfs spec: can you have a final look? https://review.openstack.org/#/c/485522/ | |
| 12:09:19 | openstackgerrit | Chris Dent proposed openstack/nova master: Use microversion parse 0.2.1 https://review.openstack.org/550265 | |
| 12:29:11 | fried_rice | Gate fixed? Time to recheck-all? | |
| 12:41:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Stop using mox in virt/xenapi/image/test_vdi_through_dev.py https://review.openstack.org/342682 | |
| 12:41:43 | fried_rice | eric-young: I don't see the os-brick release proposed yet. Need help? | |
| 12:47:16 | eric-young | fried_rice, there was some talk yesterday in the cinder channel about needing one more patch merged first. was going to check on status here in a bit | |
| 12:47:34 | fried_rice | eric-young: Roger that, just checking in :) | |
| 12:48:17 | fried_rice | (I'm in no hurry, just saw the nova patch go by again this morning) | |
| 12:49:24 | eric-young | fried_rice, I am in no super hurry either but it'd be good to get that patch off my plate :) | |
| 12:50:49 | eric-young | also need to get zuul to approve it. seeing an error with tempest-full-py3 on POST_FAILURE | |
| 13:01:43 | leakypipes | sususuryashines: welcome to Friday :) | |
| 13:02:38 | kashyap | leakypipes: You've got one hell of a plumbing expenses there :P | |
| 13:02:46 | kashyap | s/expenses/bill/ | |
| 13:03:01 | sususuryashines | leakypipes : hehe, thanks! | |
| 13:03:22 | leakypipes | kashyap: indeed. | |
| 13:07:02 | fried_rice | eric-young: That one should be recheckable now. | |
| 13:12:37 | eric-young | thanks, will do | |
| 13:19:29 | sq4ind | hey guys, any way to recover VM which has been lost during live migration ? I cannot find it on any hypervisor | |
| 13:19:39 | sq4ind | tried this already: https://docs.openstack.org/nova/latest/admin/node-down.html | |
| 13:19:46 | sq4ind | no luck ;/ | |
| 13:23:35 | openstackgerrit | Merged openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522 | |
| 13:27:48 | openstackgerrit | Patricia Domingues proposed openstack/nova master: load up the volume drivers by checking architecture https://review.openstack.org/541393 | |
| 13:34:28 | dansmith | johnthetubaguy: https://review.openstack.org/#/c/539605 | |
| 13:38:24 | giblet | fried_rice, leakypipes: when placement was designed was it intentionaly decided that placement does not provide information about which part of an allocation candidate fulfills which part of the request? | |
| 13:39:22 | fried_rice | giblet: That seems like it would be a tough thing to design, implement, reason about. | |
| 13:39:23 | giblet | fried_rice, leakypipes: I'm hit the issue that Neutron needs to know which part of an allocation record fulfills the original resource request of a given port | |
| 13:39:35 | bauwser | fried_rice: leakypipes: I have a question for you about https://review.openstack.org/#/c/552924/ | |
| 13:39:36 | leakypipes | giblet: not sure I follow you... an allocation request does indeed indicate which resources are served by which providers... | |
| 13:40:19 | fried_rice | giblet: Ah, yes, that's legitimate, and an issue that virt drivers will also have. It's going to come down to neutron needing to be able to map RP IDs/names to something that lets it know which real resource it corresponds to. | |
| 13:40:48 | bauwser | fried_rice: leakypipes: if we split the compute resources in between NUMA nodes (like for vCPUs), if a guest is asking for 2 vCPUs, would it be possible to have one vCPU in one NUMA node and the other vCPU in a separate node ? | |
| 13:41:01 | bauwser | like we do at the moment? | |
| 13:41:12 | fried_rice | bauwser: only if you specify them in separate request groups. | |
| 13:41:28 | bauwser | fried_rice: that's my concern | |
| 13:41:47 | giblet | leakypipes: true, the allocation request is created against an RP, but the connection between an allocation request and the original resource request of a port is missing | |
| 13:41:56 | fried_rice | bauwser: ...or if the driver models them in a single RP. I.e. the host is set up not to do NUMA at all. | |
| 13:42:08 | bauwser | fried_rice: leakypipes: for the moment, say I have two NUMA nodes with 4 pCPUs each one | |
| 13:42:17 | leakypipes | giblet: I'm not following you... | |
| 13:42:37 | fried_rice | giblet: I think what we're getting at is: if you're having trouble making that connection, it's because you didn't split up your RPs enough. | |
| 13:43:04 | bauwser | fried_rice: leakypipes: if 3 pCPUs are already taken, I can still have a instance using two pCPUs from two different NUMA nodes | |
| 13:43:28 | bauwser | fried_rice: leakypipes: if we say we need to have a request query for that, then it would be a problem | |
| 13:43:33 | giblet | fried_rice: OK that is a direction I have to investigate in the neutron port case | |
| 13:44:06 | giblet | leakypipes: there is a neturon port, that will have a resource_request, that will end up as a granular resource request group in the GET allocation_candidates query | |
| 13:44:42 | giblet | leakypipes: but parts of the returned allocation candidates does not mapps back to the original granular resource request group | |
| 13:45:21 | giblet | leakypipes: I means placement does not specify which subset of an allocation candidate maps to a certain granular resource group | |
| 13:45:46 | fried_rice | giblet: That's correct, but it also shouldn't need to. | |
| 13:45:51 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: RP delete inventories (v1.5) https://review.openstack.org/514642 | |
| 13:45:51 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: RP list: member_of and resources parameters (v1.3, v1.4) https://review.openstack.org/511183 | |
| 13:45:52 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 13:45:53 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 13:45:54 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 13:45:54 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 13:45:55 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 13:45:55 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 13:45:56 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 13:45:57 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 13:45:57 | openstackgerrit | Bence Romsics proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 13:46:39 | fried_rice | giblet: Because if you have two request groups that otherwise look the same, then it shouldn't matter which of those two pieces of the response you "use" for which. | |
| 13:46:45 | kashyap | superdan: BTW, thanks for the validation question, that prompted me to file the bug that I needed to, for the new libvirt API: https://review.openstack.org/#/c/534384/10/nova/conf/libvirt.py | |
| 13:46:52 | giblet | leakypipes, fried_rice: port1 and port2 both needs BW resource, an allocation candidate will have RP - BW pairs for both port1 and port2 but there is no way to tell which pair maps to which port | |
| 13:46:56 | kashyap | superdan: And the libvirt dev already assigned it to himself and working on it :-) | |
| 13:47:07 | fried_rice | But if the request groups were differentiated by, say, a custom trait indicating a physical network, then those traits will be in the provider summary, and you can use that to distinguish. | |
| 13:47:07 | superdan | kashyap: cool | |
| 13:47:32 | kashyap | superdan: Appreciate the eagle eyes. | |
| 13:47:40 | giblet | fried_rice: true, the response is not ambigous. It is just haaard to make a generic code that does the mapping | |
| 13:47:46 | leakypipes | giblet: the provider_summaries section of the allocation candidates response contains all the trait and usage information that callers would need to decide that mapping, though. | |
| 13:47:49 | fried_rice | giblet: Well, you'd have to do the math, yeah. | |
| 13:48:05 | fried_rice | which I agree is awkward | |
| 13:48:14 | giblet | leakypipes, fried_rice: thanks, I understand now | |
| 13:48:20 | giblet | a bit better... | |
| 13:49:02 | fried_rice | bauwser: As we've currently got things conceived, if you want to do a don't-care-about-NUMA-affinity resource request on a system that's set up for NUMA, you should split your CPU resources into separate request groups. | |
| 13:49:40 | fried_rice | bauwser: It's awkward, but without further invention, it's the only way to guarantee that you'd be able to get a result spread across multiple nodes if you need. | |
| 13:49:43 | bauwser | fried_rice: not sure I understand the latter | |
| 13:50:09 | bauwser | WDYM by splitting your resources into separate groups ? | |
| 13:50:31 | kashyap | superdan: Do you absolutely want me to remove the white space change? https://review.openstack.org/#/c/534384/10/nova/virt/libvirt/driver.py | |
| 13:50:32 | fried_rice | bauwser: Instead of resources=VCPU:2, which would always give you both VCPUs from the same provider, you would have to say resources1=VCPU:1&resources2=VCPU:1 | |
| 13:50:41 | superdan | kashyap: I absolutely do | |
| 13:50:56 | kashyap | superdan: :-) Did it to keep the conditionals in line. But where is the next chance to "fix it"? | |
| 13:50:59 | bauwser | fried_rice: that looks a terrible upgrade impact for operators IMHO | |
| 13:51:09 | kashyap | A separate change just to do that is overkill | |
| 13:51:14 | superdan | kashyap: it's not worth fixing, IMHO | |
| 13:51:28 | kashyap | Okay, I'll curb my OCD there | |
| 13:51:33 | bauwser | as an operator, I just want to provide flavors, either for specific NUMA calls, or just for asking resources | |
| 13:51:34 | leakypipes | bauwser, giblet, fried_rice: I'm almost done reworking the cpu-resources spec with all the feedback from yesterday's 6-hour sage IRC conversation. Gimme about an hour and the new spec should answer a number of your questions. | |
| 13:51:34 | fried_rice | bauwser: Again, without further invention, that's the way it's got to be. Think about the implications if we supported splitting a single VCPU:2 across multiple RPs. | |
| 13:52:01 | bauwser | fried_rice: we haven't modeled NUMA yet, hence my questions | |
| 13:52:11 | sean-k-mooney[m] | Fried_rice thats concering as if i have a gust that can't fit on a single numa node i cant boot that anymore if i dont request a multi numa topology | |
| 13:52:27 | bauwser | fried_rice: if we go sharding the resources between NUMA nodes, then that's a terrible operator impact IMHO | |
| 13:52:31 | fried_rice | bauwser: The example I gave was DISK_GB. If I say resources=DISK_GB:1024, but my compute host has multiple storage RPs (including shared), I definitely don't want GET /a_c to return me candidates where those DISK_GB are split across multiple. | |
| 13:52:35 | bauwser | that needs at least to be properly documented | |
| 13:53:08 | bauwser | fried_rice: again, I understand nested RPs | |
| 13:53:15 | bauwser | fried_rice: so, yeah I agree | |
| 13:53:22 | fried_rice | bauwser: That goes for nested and sharing alike. | |
| 13:53:35 | bauwser | fried_rice: if you shard your resources between separate nested children, then it's understandable | |
| 13:53:45 | bauwser | fried_rice: but here I'm talking of NUMA | |
| 13:53:50 | sahid | leakypipes: mriedem, thanks for your efforts on reviewing the trusted vfs specs | |
| 13:53:53 | fried_rice | bauwser: I don't disagree that this is awkward. But we would have to come up with some new semantic to allow spreading. resources=VCPU:2&allow_spread=resources | |