Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-15
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
18:42:54 dansmith alright :D
18:45:01 prometheanfire ok, looks like just uploading the cirros image twice will work for this usage at least
18:55:43 dansmith prometheanfire: you and your crazy requests.. next I'm sure you'll be asking us to run live migrations at more than 1MB/s!
18:56:16 prometheanfire dansmith: well, that would be nice, but seems you already did that :P
18:56:27 dansmith hehe
20:30:43 efried cfriesen: Re https://review.openstack.org/#/c/590041/ -- do the examples in the commit message look appropriately useful to you? Any suggestions for improvement or whatever?
20:50:38 openstackgerrit Doug Hellmann proposed openstack/nova master: use static pages for mitaka and newton release notes https://review.openstack.org/592150
20:54:41 openstackgerrit Dmitry Sutyagin proposed openstack/nova master: libvirt: add disabling KSM via flavor extra specs https://review.openstack.org/591854
21:29:19 cfriesen efried: that looks useful. It occurs to me that it might be useful to list *which* providers were found to see which ones were ruled out at each step. (Not sure if that'd be too verbose or not.)
21:30:03 efried cfriesen: Yeah, and we'd probably be talking about printing a bunch of UUIDs, which might not be especially readable anyway.
21:30:16 efried cfriesen: Though something like that could be considered for TRACE level...
21:32:28 cfriesen sounds reasonable. what you've got is still a significant improvement
21:52:03 openstackgerrit Merged openstack/nova master: Add placement perf info gathering hook to end of nova-next https://review.openstack.org/591367
22:21:14 efried melwitt: Agree that https://review.openstack.org/#/c/591854/ should have a reno?
22:25:08 openstackgerrit Ken'ichi Ohmichi proposed openstack/nova master: Merge extended availability zone response into server controller https://review.openstack.org/502859
22:31:25 melwitt efried: looking
22:35:19 melwitt efried: I agree it should have a reno to signal the availability of something new people can use. but I'm not clear on whether this is proposing a brand new extra spec? if it is, I think that would need at least a specless blueprint
22:35:59 efried melwitt: Okay, swhat I thought on the reno. You da boss on the bp.
22:36:01 efried thanks
22:36:12 efried melwitt: And yes, IIUC it's a brand new extra_spec.
22:36:59 melwitt okay. I'll ask mriedem about it when he's around, to get his input
22:38:06 efried melwitt: Okay, I added a note to that effect, with a reference to the doc.
22:38:52 melwitt ok, thanks
22:39:11 efried melwitt: Based on what I'm reading at https://docs.openstack.org/nova/latest/contributor/blueprints.html and https://specs.openstack.org/openstack/nova-specs/readme.html#trivial-specifications I think you're probably right.
22:41:49 melwitt efried: thanks. yeah, was also looking at the git blame to see how other extra specs were added, for example one was from https://specs.openstack.org/openstack/nova-specs/specs/ocata/approved/libvirt-emulator-threads-policy.html
22:42:36 efried mm, that one clearly not specless

Earlier   Later