| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-06-11 | |||
| 14:19:44 | artom | dansmith, ah I see - "bind-time" vs "plug-time" | |
| 14:19:49 | dansmith | something like that yeah | |
| 14:19:56 | artom | Well, except it's *very* revert specific | |
| 14:20:12 | artom | Because IIUC it doesn't happen unless the instance is present on the host, shut off | |
| 14:20:15 | dansmith | the fact that it's revert specific is a nova detail | |
| 14:20:27 | dansmith | it's specific to re-binding without changing the host, or whatever the eff it is | |
| 14:20:58 | efried | stephenfin: looks like it may have been backported, yeah. | |
| 14:20:58 | artom | Updating the binding to a host that already has the instance | |
| 14:21:20 | dansmith | artom: there's also nova/network/somethingelse | |
| 14:21:24 | dansmith | if you prefer | |
| 14:21:26 | prometheanfire | nova tests flakey? | |
| 14:21:42 | efried | prometheanfire: We think we're hitting https://bugs.launchpad.net/nova/+bug/1804062/comments/4 | |
| 14:21:43 | openstack | Launchpad bug 1804062 in nova (Ubuntu Eoan) "test_hacking fails for python 3.6.7 and newer" [High,Triaged] | |
| 14:21:49 | artom | dansmith, events.py? | |
| 14:21:56 | artom | neutronapi is fine | |
| 14:21:58 | dansmith | artom: but the detail here is pretty neutron specific, as I understand it | |
| 14:22:03 | artom | dansmith, oh yeah | |
| 14:22:04 | efried | stephenfin: I'm going to propose a patch to disable in 2.7.15, unless you're already on that. | |
| 14:22:27 | stephenfin | I was just going to fix the test | |
| 14:22:35 | efried | stephenfin: oh, what's the fix? | |
| 14:22:45 | stephenfin | No idea. I'm working on that :) | |
| 14:22:52 | dansmith | artom: if you meant nova/network/events.py as a new modiule.. maybe but that's pretty heavy.. I dunno, I don't care that much, I just don't want it in virtapi | |
| 14:22:53 | stephenfin | Wait, is this fixed in 2.7.16? | |
| 14:22:59 | dansmith | artom: I bet mriedem has an opinion | |
| 14:22:59 | stephenfin | i.e. is it a Python bug? | |
| 14:23:13 | dansmith | artom: and it's probably contrary to my opinion | |
| 14:23:35 | artom | dansmith, mriedem, well you guys can oil-wrestle it out | |
| 14:23:42 | artom | I'm gonna go write code ;) | |
| 14:23:45 | dansmith | artom: I think he likes to disagree with me because he thinks it makes him look smart, whereas I like to think agreeing with him makes _me_ look smart | |
| 14:25:27 | efried | cdent: Do you understand the issue underlying https://bugs.launchpad.net/nova/+bug/1804062/comments/4 ? | |
| 14:25:29 | openstack | Launchpad bug 1804062 in nova (Ubuntu Eoan) "test_hacking fails for python 3.6.7 and newer" [High,Triaged] | |
| 14:27:10 | efried | (whoah, that's a pretty serious regex in that hacking check) | |
| 14:27:29 | prometheanfire | efried: thanks for the pointer | |
| 14:28:08 | cdent | weird. I have no memory of any of this | |
| 14:29:11 | sean-k-mooney | cdent: efried do vmware or powervm have a similar feature to libvirt auto converge livemigation optio where the vm is slowed if the migration is taking a long time to allow it too complete | |
| 14:29:56 | efried | sean-k-mooney: I don't recall any such thing, but that doesn't mean it doesn't exist. | |
| 14:30:27 | sean-k-mooney | i dont think any driver other then libvirt support it in nova but i was wondering if it was supported by other hyperviors in general | |
| 14:30:36 | cdent | efried: I don't know if the underlying issue much matters? Basically if we take off the skip and things work, groovy, if not, we still stuck? Or are you after "can we fix the regex"? | |
| 14:30:38 | efried | actually, I think powervm live migrate might actually quiesce the vm while it's migrating | |
| 14:31:23 | cdent | sean-k-mooney: the mysteries of the DRS are beyond me. If you can think it, it probably does it if you set the right setting. | |
| 14:31:49 | kashyap | yonglihe: I've also asked the QEMU post-copy migration author/maintainer to look at the spec, too. (I myself need to re-look at it, just been buried) | |
| 14:31:59 | kashyap | (s/need/"wanted to"/) | |
| 14:32:10 | sean-k-mooney | cdent: ya i assumed that its proably done under the hood in vspher or whatever | |
| 14:32:15 | efried | cdent: Well, stephenfin is looking for a way to fix whatever we're doing in the test, but so far we're stymied on that. If it's not possible (or if it takes us longer than a few more minutes to figure out) I'd like to just disable the test. But since you touched it, and your code change implies some kind of understanding of the root cause of the breakage, I though I would ask you if you know what's going on there. | |
| 14:32:52 | cdent | my understanding was based on chasing many links through the interwebs, not understanding the tokenizer | |
| 14:33:06 | efried | okay | |
| 14:34:57 | efried | I'm trying to repro on bionic. Not happening at 2.7.15rc1 | |
| 14:35:18 | efried | aha, but does reproduce on latest | |
| 14:35:29 | stephenfin | yeah, I can't reproduce on Fedora 20 with 2.7.16 | |
| 14:35:30 | efried | which lists self as 2.7.15+ -- not helpful :( | |
| 14:42:21 | stephenfin | or 3.6.8. Hmm | |
| 14:44:23 | stephenfin | I always forget how damn big the nova repo is | |
| 14:44:37 | stephenfin | Definitely should have shallow cloned | |
| 14:52:54 | kashyap | sean-k-mooney: In that PostCopy spec, this naming sounds scary to me: "*_permit_reboot_risk" | |
| 15:03:53 | efried | stephenfin: It's looking like it's only broken at 3.6.7 (some releaselevels - at least 'final') and 2.7.15 (likewise). So we could skip those and move on with life. | |
| 15:04:10 | efried | oh, never mind, I just reproduced at 3.6.8 'final'. | |
| 15:04:13 | stephenfin | If that's the case, yup, let's do that | |
| 15:04:14 | stephenfin | damn | |
| 15:05:07 | efried | stephenfin: what's your 3.6.8 where it wasn't reproducing? | |
| 15:05:17 | efried | stephenfin: and did you remember to turn off the skip decorator? :P | |
| 15:05:39 | stephenfin | python36-3.6.8-6.fc30.x86_64 | |
| 15:05:49 | stephenfin | That only applies to 2.7, no? | |
| 15:06:00 | stephenfin | I've got it reproduced in an Ubuntu VM | |
| 15:06:12 | sean-k-mooney | kashyap: yes i agree i dont like that charaterisation which is why i suggeted other names instead | |
| 15:06:36 | efried | stephenfin: The skip decorator is skipping the test in anything >= 3.6.7 | |
| 15:07:09 | stephenfin | Sorry, yeah, 3.6 | |
| 15:07:19 | sean-k-mooney | kashyap: my -1 is mainly for the extraspec names an di have one question regarding if post copy and auto converge can be used togeter at teh qemu/libvirt layer | |
| 15:07:21 | kashyap | sean-k-mooney: Thanks. Didn't read everything yet; need a fresher mind. | |
| 15:07:38 | kashyap | sean-k-mooney: I asked Dave (PostCopy author) to also comment, FWIW. | |
| 15:07:51 | sean-k-mooney | kashyap: cool | |
| 15:07:53 | kashyap | sean-k-mooney: Another thing is, how does one prioritize between PostCopy and AutoConverge | |
| 15:08:24 | sean-k-mooney | kashyap: currently its states its an error to use both | |
| 15:09:05 | sean-k-mooney | aparently nova perfers post copy over auto converge | |
| 15:09:45 | sean-k-mooney | although if i rememebr correctly danpb prefered the idea of having auto converge enabled by default in nova and was less confindent in post copy | |
| 15:09:57 | kashyap | sean-k-mooney: That's the response: | |
| 15:09:57 | kashyap | 17:08 < kashyap> dgilbert: Can you use PostCopy and AutoConverge at the _same_ time, Dave? | |
| 15:10:00 | kashyap | 17:08 < dgilbert> hmmmm | |
| 15:10:03 | kashyap | 17:09 < dgilbert> if you can I don't think we've ever tested it | |
| 15:10:40 | kashyap | sean-k-mooney: The thing is, some workloads will be "surprized" in a bad way to realize AutoConverge is auto-enabled | |
| 15:10:43 | cfriesen | it doesn't make sense to use postcopy and autoconverge at the same time | |
| 15:11:08 | kashyap | cfriesen: Yeah, it doesn't. One needs to know WTF they're doing before they start trying things | |
| 15:11:09 | sean-k-mooney | kashyap: ya i know things like watcher | |
| 15:11:11 | cfriesen | once you've enabled postcopy it'll naturally slow down as it pulls pages over the network, no need to artificially slow it down to allow to converge | |
| 15:11:49 | sean-k-mooney | cfriesen: well autoconverge only slow it down if it failed to copy less the half of the outstanding pages in the last interval | |
| 15:11:51 | kashyap | cfriesen: Yeah, the unsatisfying answer, as usual is, "it depends on the workload" | |
| 15:12:07 | sean-k-mooney | and it does not slow down the workload intially untill a certin time has passed | |
| 15:12:27 | cfriesen | sean-k-mooney: details. :) | |
| 15:12:48 | stephenfin | printf-debugging++ | |
| 15:12:55 | sean-k-mooney | if you are dirtiying memory fast enough i dont know if post-copy is required to ever finish or if write to remote memory will always be paged to local memory instead | |
| 15:13:15 | cfriesen | sean-k-mooney: once you've written to all local pages, then post-copy is done. :) | |
| 15:13:19 | sean-k-mooney | if post-copy works by treating the remote meory as read only then its fine | |
| 15:13:25 | cfriesen | sean-k-mooney: it does | |
| 15:13:36 | sean-k-mooney | ok then ya no need to use both | |
| 15:13:44 | cfriesen | sean-k-mooney: but if you lose the network while in post-copy, you're hosed | |
| 15:13:53 | sean-k-mooney | yep i know | |
| 15:14:19 | sean-k-mooney | but if you looes netwroking with shared storage your equally screwed | |
| 15:16:01 | artom | We're allowed methods in neutronv2/api.py that aren't in network/api.py, right? | |
| 15:16:16 | artom | Or is this like virt drivers, they all need to match? | |
| 15:16:16 | sean-k-mooney | private ones yes | |
| 15:16:24 | artom | Public ones | |