| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-15 | |||
| 15:06:10 | efried | sean-k-mooney: According to that patch, which *adds* a hard fail... | |
| 15:07:24 | sean-k-mooney | efried: we used to have an api check at some point before this | |
| 15:07:46 | sapd1 | sean-k-mooney: yep. I think we have to check number of pci slots available when attach. | |
| 15:08:35 | sean-k-mooney | sapd1: yes my concern with that is is attach blocking or async | |
| 15:09:39 | sean-k-mooney | sapd1: if its a blocking call that means the api must wait for the hyperviror to try to attach the interface to the guest before returning assuming a device is available to attach | |
| 15:09:59 | tssurya | gmann: thanks a ton! | |
| 15:10:37 | sean-k-mooney | sapd1: well that is it would have to wait if we wanted to comunicate a good error message as to why the attach failed | |
| 15:11:05 | sapd1 | sean-k-mooney: So we have to save number of pci slots available in database like CPU and ram. as you said, in placement database | |
| 15:11:43 | sapd1 | then when attach port, we have to check in database. | |
| 15:11:46 | sean-k-mooney | sapd1: that is virtdriver specific. we cannot track that in placement | |
| 15:12:22 | sean-k-mooney | sapd1: we may be able to recored that in the nova db but im not sure it would apply to all drivers | |
| 15:13:03 | sapd1 | sean-k-mooney: But I don't know how to push profile of sriov port from nova-api to nova-compute | |
| 15:13:19 | jaypipes | efried: done | |
| 15:13:36 | sean-k-mooney | sapd1: profile? | |
| 15:13:59 | sean-k-mooney | sapd1: as in vif:binding_profile? | |
| 15:14:11 | sapd1 | sean-k-mooney: http://paste.openstack.org/show/726723/ | |
| 15:14:41 | sapd1 | I saw the profile of the port is not updated | |
| 15:15:39 | sean-k-mooney | ya that is because we dont generate it in the api on attach. | |
| 15:16:07 | sean-k-mooney | sapd1: you wil not be able to set that value form neutron or nova apis | |
| 15:16:53 | sapd1 | sean-k-mooney: how can I generate it? | |
| 15:17:03 | sean-k-mooney | sapd1: normally that is set by the virt_driver on the compute node during instace spawn when it does a port bind | |
| 15:17:20 | sean-k-mooney | sapd1: the virt driver is the only thing that can generate it | |
| 15:18:36 | sapd1 | sean-k-mooney: I think so, But in this (https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_sriov/agent/sriov_nic_agent.py#L70) | |
| 15:19:13 | sapd1 | nova notify port update to neutron, but port has not profile (pci_slot) so It can't update port | |
| 15:19:17 | sean-k-mooney | you cannot set this in neutron. neuton does not know what hypervior th vm is booting on | |
| 15:19:42 | sean-k-mooney | sapd1: correct. | |
| 15:21:56 | sapd1 | so I'm confusing because where can I write a patch to fix this. :D | |
| 15:23:11 | sean-k-mooney | sapd1: you would need several patches :) but the pci_slot is extracted from the pci_request_spec here https://github.com/openstack/nova/blob/c9b7c3577f373477d003706bb5ca748a51bbf023/nova/network/neutronv2/api.py#L1367-L1377 | |
| 15:25:58 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Wait for network-vif-plugged before starting live migration https://review.openstack.org/591735 | |
| 15:25:59 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: DNM: Debug patch to test live migration waiting https://review.openstack.org/591775 | |
| 15:26:00 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Fix cancel_all_events event name parsing https://review.openstack.org/592086 | |
| 15:27:16 | sean-k-mooney | sapd1: that gets indrectly called from _populate_neutron_extension_values whcih is called form _update_ports_for_instance which is called from allocate_for_instance on vm boot | |
| 15:28:37 | sapd1 | sean-k-mooney: too complicated | |
| 15:30:20 | sean-k-mooney | sapd1: i looked at doing this a few year ago. its non trival. the point is _populate_neutron_extension_values when we are doing an attach | |
| 15:31:00 | sean-k-mooney | we also dont genartate a pci_request_spec object and ask the resouce tracker for a VF | |
| 15:32:45 | sapd1 | sean-k-mooney: Can you help me with path which can generate port profile I don't need update allocated database because I would like to use with octavia only. | |
| 15:33:40 | sean-k-mooney | sapd1: the first step is to reporpose the spec for stien. | |
| 15:34:03 | sean-k-mooney | to add this fuctionality so that octavia can use it it will need to be done properly end to end | |
| 15:35:34 | openstackgerrit | Ghanshyam Mann proposed openstack/nova master: Merge extended_status extension response into server view builder https://review.openstack.org/592092 | |
| 15:35:51 | sapd1 | sean-k-mooney: wait me | |
| 15:38:57 | openstackgerrit | Merged openstack/python-novaclient master: Replace os-client-config to openstacksdk https://review.openstack.org/590141 | |
| 15:50:02 | openstackgerrit | Chen proposed openstack/nova master: Revisons on notifications doc https://review.openstack.org/591621 | |
| 15:52:39 | pvc_ | hi | |
| 15:52:49 | pvc_ | im currently using ceph backend for my voluems | |
| 15:52:58 | pvc_ | but when i extending it on a attached state it have an error | |
| 15:53:11 | pvc_ | Hypervisor is not supported the volume extension | |
| 16:04:57 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: Wait for network-vif-plugged before starting live migration https://review.openstack.org/591735 | |
| 16:04:58 | openstackgerrit | Dan Smith proposed openstack/nova stable/queens: DNM: Debug patch to test live migration waiting https://review.openstack.org/591775 | |
| 16:08:38 | tikitavi__ | Hi, can anybody help me with starting an instance with fake driver | |
| 16:08:52 | tikitavi__ | I have devstack with VIRT_DRIVER=fake in localrc, when I’m trying to start instance it fails with error “{"message": "Binding failed for port c38ac68b-3417-4443-b10d-a0d65647e9bd, please check neutron logs for more information.", "code": 400, "created": "2018-08-13T12:55:26Z”}” | |
| 16:09:04 | tikitavi__ | The error in neutron sac logs is neutron-server[23609]: ERROR neutron.plugins.ml2.managers [None req-a779fdba-0b67-4ac1-983e-551bd58cc566 service neutron] Failed to bind port c38ac68b-3417-4443-b10d-a0d65647e9bd on host ubuntu-xenial-ovh-bhs1-00012954471 for vnic_type normal using segments [{'network_id': '755c91d8-76ef-4ff4-8997-717897309695', 'segmentation_id': 86, 'physical_network': None, 'id': 'e1fb3dff-bf9c-41df-89 | |
| 16:22:21 | sapd1 | pvc_: you have to detach volume from instance then extend volume | |
| 16:25:38 | pvc_ | my goal is to extend it even if it is in attached state | |
| 16:29:39 | prometheanfire | looks like only pike remains :D https://review.openstack.org/#/c/591762 | |
| 16:35:17 | sapd1 | pvc_: * only iscsi and fibre channel volume types are supported on the nova side currently. | |
| 16:35:20 | sapd1 | https://review.openstack.org/#/c/454287/23/releasenotes/notes/support-extend-inuse-volume-9e4atf8912qaye99.yaml | |
| 16:36:56 | pvc_ | is there a blueprint for rbd? | |
| 16:40:20 | mdbooth | melwitt: Looks like there's a bug in the functional test for https://review.openstack.org/#/c/578846/ as it's failing non-deterministically. I'll try to get to the bottom of that tomorrow. However, if you could take a view on the patch itself, if only at a high level, I'd be very grateful. | |
| 16:40:55 | melwitt | mdbooth: sure, will take a look | |
| 16:41:02 | openstackgerrit | Doug Hellmann proposed openstack/nova master: use static pages for mitaka and newton release notes https://review.openstack.org/592150 | |
| 16:41:29 | mdbooth | melwitt: Thanks | |
| 16:44:30 | melwitt | sapd1: if you are interested in developing the attach/detach feature, you must first propose it as a spec for the stein release, where it can be reviewed. here is the docs on how to submit a spec: https://specs.openstack.org/openstack/nova-specs/readme.html | |
| 16:50:24 | dansmith | melwitt: tssurya: I'm assuming no cells meeting, matt is in china and I have nothing | |
| 16:50:35 | dansmith | presumably we just need to get back on the down-cell reviews... | |
| 16:50:53 | tssurya | dansmith: me neither, yea working on tests for the API stuff ^ | |
| 16:51:02 | melwitt | I don't have anything either. my server group patch has been receiving review | |
| 16:51:13 | dansmith | schweeeeet | |
| 16:51:56 | melwitt | we still have those other bugs around build request/instance mapping getting out-of-sync so we should get thinking about and reviewing those too | |
| 17:17:51 | sapd1 | melwitt: I'm trying to repropose . | |
| 17:18:52 | melwitt | sapd1: oh, hm, it looks like we don't yet have the stein directory available in nova-specs | |
| 17:20:08 | melwitt | dansmith: could you hit this to add the stein directory to nova-specs? https://review.openstack.org/573602 | |
| 17:20:38 | dansmith | cha | |
| 17:20:47 | melwitt | thx | |
| 17:27:33 | openstackgerrit | Merged openstack/nova-specs master: Create specs directory for Stein https://review.openstack.org/573602 | |
| 17:30:00 | melwitt | sapd1: okay, you'll just need to rebase to get the stein directory ^ and then you'll be able to copy the spec file there for proposal | |
| 17:30:07 | melwitt | *copy the spec into the stein directory | |
| 17:30:48 | sapd1 | Thanks melwitt | |
| 17:32:03 | openstackgerrit | Merged openstack/nova stable/queens: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591761 | |
| 17:36:38 | prometheanfire | :D | |
| 17:40:49 | openstackgerrit | Dmitry Sutyagin proposed openstack/nova master: libvirt: add disabling KSM via flavor extra specs https://review.openstack.org/591854 | |
| 17:42:31 | dansmith | prometheanfire: pike one is in the queue now | |
| 17:43:50 | prometheanfire | yep, I'm watching it | |
| 18:09:59 | prometheanfire | am I right in thinking that this patch makes it so that images with the hypervisor_type of qemu will not boot on nova nodes having virt_type=kvm? https://git.openstack.org/cgit/openstack/nova/commit/?id=eaa766ee2093c24fd61c61e52f46bdd9ff9e93d2 | |
| 18:26:01 | melwitt | I think so. dansmith? ^ | |
| 18:26:39 | dansmith | that's the point I think yeah | |
| 18:29:39 | melwitt | prometheanfire ^ | |
| 18:32:13 | dansmith | I think the goal was kindof the opposite, to make sure that kvm-requiring instances didn't boot on qemu-only hosts, but the result for your case is the same I think | |
| 18:33:17 | prometheanfire | dansmith: ok, it sounds like that means I'll have to upload images twice (once for each hypervisor_type) if I want the image to boot on both (I have other images that are ironic, which is why I need to specify type in the first place) | |
| 18:33:45 | dansmith | prometheanfire: why do you ever have images that specify qemu? | |
| 18:38:19 | prometheanfire | gating on hosts that don't allow nested virt | |
| 18:38:33 | prometheanfire | it's for that reason alone | |
| 18:40:56 | dansmith | um | |
| 18:41:11 | dansmith | just because something uses kvm type doesn't mean it supports nested virt | |
| 18:41:32 | prometheanfire | that's not what I was trying to say | |
| 18:41:43 | prometheanfire | I was trying to say some of our hosts don't have kvm | |
| 18:41:53 | dansmith | ...really? | |
| 18:42:03 | dansmith | by policy or soemthing? | |
| 18:42:13 | dansmith | I mean running in actual qemu mode is so slow, it's hard to make any real-world use case for it | |
| 18:42:17 | prometheanfire | ya | |
| 18:42:24 | prometheanfire | it's stupid | |