| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-29 | |||
| 15:37:04 | efried | acceptable | |
| 15:37:12 | bauzas | efried: just focusing on dansmith's series | |
| 15:37:18 | bauzas | but then I can help | |
| 15:37:21 | efried | thanks | |
| 15:37:24 | mriedem | bauzas: ever word in english has at least 3 different meanings | |
| 15:37:45 | mriedem | *every even | |
| 15:37:47 | efried | holy shit, I just looked back at that etherpad. | |
| 15:37:48 | bauzas | efried: food for thoughts too https://review.openstack.org/#/c/557065/ | |
| 15:37:56 | bauzas | efried: since you asked me about that | |
| 15:38:02 | efried | bauzas: ack | |
| 15:38:09 | efried | brb... | |
| 15:38:11 | bauzas | I'm not a big fan of a nova-manage command just for that | |
| 15:38:36 | bauzas | if one day libvirt provides the API to set this, then we would deprecate the conf option | |
| 15:38:55 | bauzas | while a nova-manage command for a very specific libvirt hack makes me worried by the precedence | |
| 15:42:57 | bauzas | gibi: happy travels | |
| 15:43:45 | cdent | happy honeymoon gibi | |
| 15:45:14 | melwitt | o/ gibi | |
| 15:49:08 | alex_xu_ | jaypipes: FPGA_FUNCTION_X,y,z, I guess | |
| 15:49:24 | alex_xu_ | jaypipes: and I thought we should have a trait FPGA_DEVICE_PRE_PROGRAMMED | |
| 15:49:38 | openstackgerrit | Mathieu Gagné proposed openstack/nova master: Fix rebuild of baremetal instance when vm_state is ERROR https://review.openstack.org/523559 | |
| 15:53:47 | dansmith | mriedem: to use osc-placement do I have to tell osc to use a specific microversion? | |
| 15:54:12 | dansmith | getting "Operation or argument is not supported with version 1.0" | |
| 15:54:59 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Fix bad management of _TRAITS_SYNCED flag https://review.openstack.org/557722 | |
| 15:55:34 | openstackgerrit | Merged openstack/nova stable/queens: add check before adding cpus to cpuset_reserved https://review.openstack.org/557621 | |
| 15:55:55 | mriedem | dansmith: yup | |
| 15:56:02 | mriedem | osc doesn't default to latest like nova cli does | |
| 15:56:31 | dansmith | yeah I found it | |
| 15:56:35 | jaypipes | gibi: congrats again and have a great time on your honeymoon, man :) | |
| 15:57:16 | mriedem | get used to always being wrong | |
| 16:10:27 | openstackgerrit | Dan Smith proposed openstack/nova master: Documentation for tenant isolation with placement https://review.openstack.org/557490 | |
| 16:10:42 | dansmith | mriedem: wanna glance at this ^ before I shut down my devstack node I used to generate the command outputs? | |
| 16:18:34 | mriedem | please hold | |
| 16:18:40 | efried | dansmith, jaypipes, edleafe, cdent, bauzas, alex_xu_: I'm caught up on the etherpad now. I think there's actually agreement on the salient points. The discussion of "capable of X" versus "flashed with X" is orthogonal. (Still relevant, still needing discussion, but the outcome doesn't affect the rest.) Good if I summarize and respond on the ML? | |
| 16:18:42 | mriedem | https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/hypervisor.html#hypervisor-list | |
| 16:18:45 | mriedem | dansmith: let's use osc | |
| 16:18:54 | dansmith | mriedem: it doesn't show id | |
| 16:19:05 | mriedem | --os-compute-api-version 2.53 | |
| 16:19:13 | dansmith | I also thought we were still recommending novaclient for admin things? | |
| 16:19:42 | edleafe | efried: the problem was that jaypipes strongly objected to the "capable of X" traits | |
| 16:19:48 | dansmith | also the long --foo-version things really muck up the output, just by the way | |
| 16:19:51 | mriedem | i've got a guy here for some stuff so need to be afk for a bit | |
| 16:20:00 | jaypipes | efried: I'm fine with you summarizing on the ML, though it does seem from the etherpad that there are still a number of things that are still not agreed on. | |
| 16:20:03 | mriedem | you can set an env var early if you want | |
| 16:20:05 | efried | edleafe: I'm saying that discussion is tangential | |
| 16:20:12 | mriedem | export OS_COMPUTE_API_VERSION=2.53 | |
| 16:20:49 | dansmith | well, that makes them less copy/pasteable in isolation | |
| 16:20:53 | dansmith | just saying, it's annoyiung | |
| 16:23:20 | melwitt | lyarwood: can you pls remove the -W on this? https://review.openstack.org/#/c/550498/ queens change merged | |
| 16:23:39 | lyarwood | melwitt: done | |
| 16:23:44 | melwitt | woot thanks | |
| 16:26:19 | openstackgerrit | Dan Smith proposed openstack/nova master: Documentation for tenant isolation with placement https://review.openstack.org/557490 | |
| 16:26:25 | dansmith | mriedem: like that ^ ? | |
| 16:43:39 | efried | edleafe, jaypipes: You'll notice I neatly sidestepped the issue of "capable-of-X" vs "has-X" traits :P | |
| 16:45:05 | edleafe | efried: in meeting - will read soon | |
| 16:47:03 | jaypipes | efried: still trying to get through all the reading... | |
| 16:47:08 | jaypipes | efried: on the ML post. | |
| 16:49:29 | dansmith | I'm not sure what to comment on at this point, maybe we need to re-summarize at the top again with the feedback and iterate? | |
| 17:10:58 | mriedem | dansmith: yup, thanks. comments inline | |
| 17:17:00 | efried | dansmith: If you're talking about the etherpad, I summarized on the ML already. | |
| 17:19:11 | melwitt | nice job on those, good stuff | |
| 17:30:27 | jmlowe_ | I'm hunting down kind of a strange problem, the initial symptom is that the addFixedIp server action returns 202 but the fixed ip is never really added, I go digging and I find "Network could not be found for instance" in the logs of the compute node, further digging reveals that the device_owner of the port is compute:zone-r7 and it is filtered because the availability zone of the instance is zone-r2 leaving an empty list | |
| 17:30:27 | jmlowe_ | of ports and a no network found error | |
| 17:32:56 | jmlowe_ | I'm left with 3 questions, why isn't the port device_owner updated during unshelve, why does the port have to match the AZ of the instance and not just the instance and network id, are there any open bugs for this because this is nearly impossible to search for | |
| 17:34:12 | efried | jmlowe_: The only part of that I can address is the 202, which means "I understand your request; now I'm going to go away and process it asynchronously." So it's not a bug that you got 202 but the thingy ultimately failed. | |
| 17:35:12 | jmlowe_ | That's what I figured, in a perfect world the application would move on to higher microversions and interact with neutron | |
| 17:37:25 | jmlowe_ | The quick and dirty patch would be to eliminate device owner as a search opt leaving device_id and network_id, but I don't understand the logic of having it so I may be missing some subtlety about why it's there | |
| 17:39:58 | jmlowe_ | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L1459 | |
| 17:40:38 | mriedem | jmlowe_: it's likely an old ass bug in shelve where the device_owner isn't cleared | |
| 17:40:47 | jmlowe_ | Yea! | |
| 17:40:49 | mriedem | when you unshelve, the instance is re-created on a new compute node | |
| 17:40:53 | mriedem | which could be in some other AZ | |
| 17:41:45 | jmlowe_ | correct, I believe that's what I'm seeing, I haven't followed the code to find the place where it should be updating | |
| 17:41:51 | melwitt | jmlowe_: congrats, you got shelved | |
| 17:41:56 | mriedem | heh | |
| 17:42:02 | mriedem | shelving at the speed of business | |
| 17:42:52 | fghaas | Hi everyone. I have a question about enabling nested KVM, or for that matter passing in any required CPU features to an instance, in combination with using a "custom" cpu-mode. My compute nodes (Ocata) are configured to run with cpu_mode=custom, cpu_model=IvyBridge. They are also configured for nested KVM per the kvm_intel nested=Y module parameter. virsh capabilities on any compute node correctly yields <feature name='vmx'/> for the host CPU. | |
| 17:42:52 | fghaas | Now, when I schedule an instance to that compute node, it ends up with a CPU configuration as shown in http://paste.openstack.org/show/717923/, which means it is not capable of doing any nested KVM. If I then log onto the compute node, and hack the libvirt domain config with virsh edit, and I fix up the CPU configuration to match http://paste.openstack.org/show/717934/, then I can virsh shutdown/virsh start the domain and when it comes back up, voil | |
| 17:42:52 | fghaas | So my question is, do I have any way to inject that |
|
| 17:42:52 | jmlowe_ | It's a cloud for researchers, so there's a lot of "wait I need that" 6 months later | |
| 17:43:31 | mriedem | jmlowe_: there is no network deallocation on the compute that happens during shelve offload because the point of shelve is that the ports and volumes are still attached to the instance so they can be re-attached on unshelve, | |
| 17:43:50 | mriedem | jmlowe_: but chances are, https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4837 is the place we'd want to clear the device_owner on any ports attached to the instance during shelve offload | |
| 17:44:33 | jmlowe_ | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2584 | |
| 17:44:33 | mriedem | cleanup_instance_network_on_host today is a no-op for neutron in nova | |
| 17:44:51 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2517 | |
| 17:44:54 | melwitt | fghaas: cfriesen might be the person to ask about that | |
| 17:45:24 | jmlowe_ | I was really hoping somebody just forgot to slip in a _update_port_binding_for_instance call | |
| 17:45:42 | mriedem | you're looking at the wrong method | |
| 17:45:47 | mriedem | the binding stuff is called from setup_instance_network_on_host | |
| 17:46:22 | mriedem | setup is called on unshelve | |
| 17:46:24 | mriedem | b/c you're on a new host | |
| 17:46:34 | mriedem | cleanup is called from shelve offload b/c you're leaving that host | |
| 17:46:59 | mriedem | jmlowe_: so likely all we need to do is in https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L2517, get the ports for the instance, and clear their device_owner | |
| 17:47:08 | mriedem | since that's tied to the az which is tied to the host | |
| 17:47:15 | fghaas | melwitt: thanks, I'll keep my eyes peeled for cfriesen's thoughts then :) | |
| 17:47:43 | mriedem | jmlowe_: what i'm not sure about, is if that will screw with neutron if the device_owner is null but the binding:host_id is still set | |
| 17:47:57 | mriedem | https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L515 | |
| 17:48:14 | mriedem | we basically want ^ but we want to retain the port.device_id | |
| 17:48:44 | cdent | mriedem: why is it when you find and fix a race that race starts showing up all over the damn place (when it wasn't beore)? | |
| 17:49:05 | mriedem | because software is terrible | |
| 17:49:24 | mriedem | why doesn't shelve work after 7 years? | |