Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-15
14:58:20 openstackgerrit Matthew Booth proposed openstack/nova master: Py3 fix in fake image service https://review.openstack.org/592056
14:59:01 sapd1 octavia-lb-vrrp port is created and attached to amphora instance after instance is created.
15:00:23 sean-k-mooney sapd1: right. so im personally ok with adding attach/detach for sriov interfaces but are you aware that the process is more complicated now then it was in newton
15:01:34 sean-k-mooney one of the hopes for stien is that we would start tracking VFs in placement, so you would have to update the instance allocation in placement
15:02:16 sean-k-mooney addtionaly assuming the vm is on a host that has an available VF attached to the correct physnet
15:02:46 sapd1 sean-k-mooney: yep. It's more complicated with me
15:03:20 sean-k-mooney the vm may or may not have enough pci slots available for the VF to be attached. this also changes depending on if the vm is using the qemu Q35 chipset in the libvirt driver case
15:04:15 efried sapd1: keep an eye on https://review.openstack.org/#/c/591898/ -- I'm hoping this evolves to make SRIOV hot (un)plug based on a driver capability, but either way you'll need to work with it to do your support.
15:05:41 sean-k-mooney efried: we used to hard fail in old releases for sriov attach
15:05:56 sean-k-mooney efried: do you know if the current attach api call is blocking
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

Earlier   Later