| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-12 | |||
| 15:34:52 | dansmith | lyarwood: you said you were going to work on this this cycle right? | |
| 15:35:52 | lyarwood | dansmith: yup I should actually have time this cycle | |
| 15:36:10 | dansmith | lyarwood: cool, I | |
| 15:36:23 | dansmith | I would suggest getting this going sooner than later if you can schedule it | |
| 15:36:39 | dansmith | at least rebase the code and get it restored so that others can comment/help | |
| 15:37:01 | dansmith | even if before the spec, although I think the spec is easy to merge pretty soon if you fix up the issues | |
| 15:37:33 | lyarwood | dansmith: sure, I should be able to get something rebased pretty quickly. | |
| 15:37:36 | lyarwood | famous last words | |
| 15:41:03 | efried | jroll: randomly generated passphrase: do you think there should be a conf option for the length? If so/not, what should the default/number be? | |
| 15:49:24 | jroll | efried: probably not worth a config until/unless someone asks. 32 or 64 characters seems reasonable | |
| 15:50:19 | efried | Roger that. (Glad I asked, I was gonna go 256 :P ) | |
| 15:50:37 | jroll | 256 is also reasonable :D | |
| 15:50:37 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Wire up a force disconnect_volume flag https://review.opendev.org/584849 | |
| 15:51:18 | jroll | efried: I guess if nobody ever touches this, maybe 256 is a better option | |
| 15:51:47 | efried | it certainly won't be readable/typable. Like an ssh key. How big are those? | |
| 15:52:45 | jroll | $ wc ~/.ssh/id_rsa | |
| 15:52:47 | jroll | 54 61 3326 /Users/jrollenhagen/.ssh/id_rsa | |
| 15:53:43 | efried | yours is bigger than mine | |
| 15:53:53 | dansmith | mriedem: wha-chu-think main? https://review.opendev.org/#/c/636224/50/nova/compute/api.py | |
| 15:53:59 | jroll | heh | |
| 15:54:01 | dansmith | efried: whoa, wrong channel | |
| 15:54:44 | efried | that's number of chars, b64-encoded, plus header/footer | |
| 15:55:42 | jroll | right, looks like 3072 bytes | |
| 15:55:51 | mriedem | dansmith: you can't compare None values can you? | |
| 15:56:41 | dansmith | mriedem: you can | |
| 15:57:13 | dansmith | mriedem: >>> (None, 1) < (None, 2) | |
| 15:57:13 | dansmith | True | |
| 15:57:26 | mriedem | >>> datetime.datetime.today() < None | |
| 15:57:26 | mriedem | Traceback (most recent call last): | |
| 15:57:26 | mriedem | File "<stdin>", line 1, in <module> | |
| 15:57:26 | mriedem | TypeError: can't compare datetime.datetime to NoneType | |
| 15:57:37 | mriedem | i guess because of the tuples | |
| 15:57:42 | bauzas | AFAIR, you were even able to say something like None = 2 | |
| 15:57:43 | dansmith | oh you mean compare datetime to none | |
| 15:57:48 | bauzas | in py2 something | |
| 15:57:49 | mriedem | that's what these are | |
| 15:58:42 | mriedem | >>> now1 = datetime.datetime.now() | |
| 15:58:43 | mriedem | >>> now2 = datetime.datetime.now() | |
| 15:58:43 | mriedem | >>> now1 < now2 | |
| 15:58:43 | mriedem | True | |
| 15:58:43 | mriedem | >>> now1 < None | |
| 15:58:43 | mriedem | Traceback (most recent call last): | |
| 15:58:43 | mriedem | File "<stdin>", line 1, in <module> | |
| 15:58:44 | mriedem | TypeError: can't compare datetime.datetime to NoneType | |
| 15:58:55 | dansmith | yeah, ack | |
| 15:58:56 | efried | jroll: afaict those would map to original random passphrases of ~1200-2400 chars | |
| 15:59:06 | Roamer` | mriedem, you'd get the same result if you tried to compare it to "whee" or to 17 | |
| 15:59:31 | dansmith | mriedem: we have to find something better than what you have | |
| 15:59:49 | Roamer` | ah, but you're commenting on the patch in the review request, sorry, yeah | |
| 16:00:20 | mriedem | dansmith: i looked for some builtin sorting/filtering type function but didn't find anything obvious | |
| 16:01:12 | dansmith | okay I got it | |
| 16:01:51 | mriedem | sorted with a key function? | |
| 16:02:44 | mdbooth | lyarwood: https://review.opendev.org/#/c/584850/ | |
| 16:02:47 | kashyap | Is this a common convention? "os-migrateLive" | |
| 16:02:54 | dansmith | mriedem: https://pastebin.com/pHtM7iEf | |
| 16:03:09 | kashyap | (I'll ask there) | |
| 16:03:15 | mdbooth | lyarwood: I know that's abandoned, but any idea where that came from? The concept of having un-flushed data after LM switchover is disturbing. | |
| 16:03:20 | Roamer` | mriedem, dansmith, maybe something like (yeah, I know, quite unwieldy) `dtnull = datetime.datetime.utcfromtimestamp(0)` and then `(u1 or dtnull, a1 or dtnull) < (u1 or dtnull, a2 or dtnull)` | |
| 16:03:45 | dansmith | Roamer`: yep, or that | |
| 16:03:47 | Roamer` | (with the correct variable names, of course, pfheh) | |
| 16:05:00 | dansmith | mine makes anything with an updated_at win and short circuit before comparing the updated_ats which means you won't ever compare non-nones | |
| 16:05:09 | dansmith | er, Non-None to None | |
| 16:06:11 | lyarwood | mdbooth: os-brick had a number of bugs around multiple devices getting grouped under the same mpath device blocking the final flush/removal on disconnect | |
| 16:06:21 | Roamer` | dansmith, TBH, I hadn't seen yours before writing mine :) it took me a while to test it and copy it here, yours might be better and less unwieldy :) | |
| 16:06:33 | lyarwood | mdbooth: QEMU's own flush was enough to ensure everything made it to the backend before we forced anything in that case | |
| 16:07:11 | mdbooth | lyarwood: That flush was happening on the source node, after switchover? | |
| 16:07:26 | lyarwood | mdbooth: the QEMU flush? | |
| 16:07:40 | lyarwood | mdbooth: no that's before we converge iirc | |
| 16:07:44 | lyarwood | or maybe during | |
| 16:07:47 | mdbooth | lyarwood: os-brick's flush on disconnect | |
| 16:08:11 | mdbooth | So the bug was that os-brick thought it had data to flush, but it didn't really? | |
| 16:08:31 | lyarwood | mdbooth: that's after but it's just something you have to do before disconnecting mpath devices iirc, there's no data actually cached anywhere at that point | |
| 16:08:56 | mdbooth | Right. It would just be really bad if there really was data to flush at that point. | |
| 16:09:48 | lyarwood | yup | |
| 16:10:01 | dansmith | jroll: didn't you add some ironic grouping construct so that one ironic can serve independent pools of nodes to dedicated nova computes? | |
| 16:10:28 | dansmith | ah, conductor groups | |
| 16:15:11 | belmoreira | dansmith jroll how that would work? | |
| 16:15:23 | dansmith | belmoreira: did you read the spec I just sent you? :) | |
| 16:15:49 | belmoreira | :) maybe... which one? :) | |
| 16:15:58 | dansmith | belmoreira: https://docs.openstack.org/ironic/latest/admin/conductor-groups.html | |
| 16:16:09 | dansmith | oops, | |
| 16:16:16 | dansmith | belmoreira: https://specs.openstack.org/openstack/nova-specs/specs/stein/implemented/ironic-conductor-groups.html | |
| 16:16:52 | belmoreira | this is train | |
| 16:17:07 | dansmith | what is? | |
| 16:17:48 | belmoreira | sorry. This is available in Stein | |
| 16:17:52 | dansmith | right | |
| 16:21:18 | belmoreira | I forgot about it. sorry. This is great however means that we will need to scale nova-compute in the same way as the ironic-conductor | |
| 16:21:56 | dansmith | belmoreira: well, you probably should be doing that anyway given you're hitting nova-compute scale issues when you make ironic big :) | |
| 16:22:51 | dansmith | I understand the desire to make the RT loop in nova-compute more efficient, and I'm sure we can without breaking things, but it's a change to complex crufty code that only (positively) impacts the one oddball driver that uses multiple nodes, | |
| 16:23:28 | dansmith | so I'm less enthusiastic about that, especially when grouping nova-computes gets you a lot more gain too, | |
| 16:23:29 | dansmith | like better fault tolerance, mapping your existing failure domains through to ironic, etc | |
| 16:24:04 | belmoreira | dansmith I understand that. That's why the initial plan was the sharding. And I wasn't aware (forgot) about the conductor groups | |
| 16:24:12 | belmoreira | this can make it | |
| 16:24:33 | dansmith | cool | |
| 16:31:01 | belmoreira | Thanks dansmith | |
| 16:31:33 | belmoreira | I will try this and let you know how it goes | |
| 16:32:23 | jroll | \o/ | |
| 16:33:57 | kashyap | mdbooth: On that "no_performance_impact" thing for post-copy / auto-converge spec, I have to bike-shed: the name is too generic for my taste. I suggested being more clear WTF it is doing: "no_post_copy_and_auto_converge". | |
| 16:34:23 | dansmith | belmoreira: sweet that'd be super | |
| 16:38:07 | openstackgerrit | Lee Yarwood proposed openstack/nova-specs master: WIP Virtual instance rescue with stable disk devices https://review.opendev.org/693849 | |