| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-15 | |||
| 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 | |
| 22:43:41 | melwitt | yeah. but for this one, it seems small enough that specless is my expectation, but I'll run it by mriedem and dansmith because sometimes a lot of questions arise and if that happens, a spec would be more appropriate | |
| 22:44:10 | melwitt | I can't say I know anyting about KSM myself | |
| 22:44:15 | melwitt | *anything | |
| 22:59:07 | efried | melwitt: Oh, technically I'm relying on sahid and sean-k-mooney to vet it. Procedurally... yeah, Matt and Dan. | |
| 23:00:27 | dansmith | I dunno about the claim that windows crashes when KSM is used.. can't really think of any reason that would be | |
| 23:00:35 | dansmith | normally I think of KSM as being a host decision or not, | |
| 23:00:46 | dansmith | so I'm kinda unsure about why we'd want it to be per-flavor | |
| 23:01:02 | dansmith | especially since it would affect your memory overcommit calculations | |
| 23:01:21 | dansmith | I would think you'd want to keep KSMing and non-KSMing instances separated by aggregate anyway | |
| 23:01:57 | dansmith | so I mean, that all leads me to think that it's probably worth a spec just on that basis | |
| 23:02:12 | dansmith | the other being that we want to make sure that we're not just plumbing a libvirt feature straight out the API | |