| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-15 | |||
| 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. | |
| 23:06:54 | dansmith | right, | |
| 23:06:57 | dansmith | it can change timing semantics for sure | |
| 23:07:06 | dansmith | hence the buggy driver example | |
| 23:07:18 | dansmith | but so can swapping on the host to a much larger degree | |
| 23:08:14 | openstackgerrit | Dmitry Sutyagin proposed openstack/nova master: libvirt: add disabling KSM via flavor extra specs https://review.openstack.org/591854 | |
| 23:16:52 | openstackgerrit | Merged openstack/nova stable/pike: Revert "libvirt: slow live-migration to ensure network is ready" https://review.openstack.org/591762 | |
| 23:24:10 | dansmith | prometheanfire: ^ | |
| 23:26:34 | prometheanfire | :D | |
| #openstack-nova - 2018-08-16 | |||
| 00:44:43 | mriedem | 你好 | |
| 00:47:56 | mriedem | smcginnis: if you're around, we need stable cores for https://review.openstack.org/#/c/591872/ RC2 | |
| 00:48:46 | mriedem | anyone know if jichen is going to clean this up? https://review.openstack.org/#/c/533125/ | |
| 00:48:53 | mriedem | efried: do we need to just update it ourselves? | |
| 00:51:16 | openstackgerrit | Merged openstack/nova master: Fix service list for disabled compute using MC driver https://review.openstack.org/583936 | |
| 00:51:25 | openstackgerrit | Merged openstack/nova master: Revisons on notifications doc https://review.openstack.org/591621 | |
| 00:51:32 | openstackgerrit | Merged openstack/nova master: use static pages for mitaka and newton release notes https://review.openstack.org/592150 | |
| 00:52:56 | mriedem | tonyb: i guess you'd be a more appropriately time-zoned stable core for https://review.openstack.org/#/c/591872/ for RC2 | |
| 00:54:40 | mriedem | Kevin_Zheng: want to start backporting https://review.openstack.org/#/c/583936/ ? it needs to go to rocky, queens and pike | |
| 00:54:47 | mriedem | we'll hold it out until we've released rocky though | |
| 00:55:01 | tonyb | mriedem: on it | |
| 01:04:32 | Kevin_Zheng | sure | |
| 01:05:31 | tonyb | mriedem: I'll ping lyarwood | |
| 01:06:10 | mriedem | tonyb: thanks but he's probably done for the day | |
| 01:07:54 | tonyb | mriedem: I can single core approve it | |
| 01:08:14 | tonyb | mriedem: given you're a stable core etc | |
| 01:09:57 | dansmith | mriedem: tonyb I got it | |
| 01:10:29 | tonyb | dansmith to the rescue! | |
| 01:24:04 | mriedem | cool; i've emailed jichen about the zvm docs since those are the only things remaining on the RC2 todo list | |
| 01:41:54 | mriedem | efried: edmondsw: frankly i care very little if the powervm out of tree driver supports a feature, i don't plan on adding flags to nova to support out of tree features, re: https://review.openstack.org/#/c/591898/ | |
| 02:10:09 | openstackgerrit | fupingxie proposed openstack/nova master: Support list for alias in pci section in nova.conf https://review.openstack.org/592243 | |
| 02:48:25 | openstackgerrit | Tao Li proposed openstack/nova master: Rollback instance vm_state to original where instance claims failed https://review.openstack.org/592252 | |
| 03:32:20 | pvc | @edmondsw im usign ceph rbd | |
| 03:52:38 | pvc | hi | |
| 03:52:43 | pvc | anyone using ceph | |