| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-23 | |||
| 10:27:13 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 10:27:15 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 10:27:16 | openstackgerrit | Huang Rui proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 10:31:09 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: RP delete inventories (v1.5) https://review.openstack.org/514642 | |
| 10:31:11 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Resource class set (v1.7) https://review.openstack.org/514644 | |
| 10:31:11 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI for traits (v1.6) https://review.openstack.org/514643 | |
| 10:31:12 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: CLI allocation candidates (v1.10) https://review.openstack.org/514647 | |
| 10:31:12 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Usages per project and user (v1.8, v1.9) https://review.openstack.org/514646 | |
| 10:31:13 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Transactionally update allocations (v1.13) https://review.openstack.org/546674 | |
| 10:31:13 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: New dict format of allocations (v1.11, v1.12) https://review.openstack.org/542819 | |
| 10:31:14 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Limit allocation candidates (v1.15, v1.16) https://review.openstack.org/548043 | |
| 10:31:14 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Add nested resource providers (v1.14) https://review.openstack.org/546675 | |
| 10:31:15 | openstackgerrit | Andrey Volkov proposed openstack/osc-placement master: Allocation candidates parameter: required (v1.17) https://review.openstack.org/548326 | |
| 10:35:45 | kashyap | sean-k-mooney: Thanks for the comment here: https://review.openstack.org/#/c/534384/10/nova/virt/libvirt/driver.py | |
| 10:37:24 | openstackgerrit | Merged openstack/nova master: Not use thread alloc policy for emulator thread https://review.openstack.org/538700 | |
| 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 | |