Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-08-15
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
23:02:31 melwitt ack, thanks dansmith
23:02:35 dansmith and we should get input from the other virt drivers on whether they have similar technologies and make sure we can drive them with the same tunable
23:02:48 dansmith like, whether or not they allow it per-VM or only per-host
23:03:00 dansmith and whether it's just on or off, ro, rw, off, etc
23:04:16 dansmith I'd surely not want to add this just because someone thinks windows is destabilized by KSM, or because they have some weird unstable driver and turning KSM off changes some race semantics or something
23:05:45 cfriesen I could see KSM causing brief interruptions to the guest, but I wouldn't expect it to cause actual hangs.

Earlier   Later