| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-12 | |||
| 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 | True | |
| 15:57:13 | dansmith | mriedem: >>> (None, 1) < (None, 2) | |
| 15:57:26 | mriedem | TypeError: can't compare datetime.datetime to NoneType | |
| 15:57:26 | mriedem | File "<stdin>", line 1, in <module> | |
| 15:57:26 | mriedem | Traceback (most recent call last): | |
| 15:57:26 | mriedem | >>> datetime.datetime.today() < None | |
| 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 | File "<stdin>", line 1, in <module> | |
| 15:58:43 | mriedem | Traceback (most recent call last): | |
| 15:58:43 | mriedem | >>> now1 < None | |
| 15:58:43 | mriedem | True | |
| 15:58:43 | mriedem | >>> now1 < now2 | |
| 15:58:43 | mriedem | >>> now2 = datetime.datetime.now() | |
| 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 | |
| 16:48:43 | dansmith | mriedem: on lyarwood's spec to do stable disk rescue, | |
| 16:48:56 | dansmith | do you have strong feelings about bundling the can-now-rescue-BFV feature in it, | |
| 16:49:03 | dansmith | vs. a relatively tiny follow-on effort? | |
| 16:56:01 | openstackgerrit | sean mooney proposed openstack/nova master: block rebuild when numa topology changed https://review.opendev.org/687957 | |
| 16:56:02 | openstackgerrit | sean mooney proposed openstack/nova master: Disable NUMATopologyFilter on rebuild https://review.opendev.org/689861 | |
| 17:02:01 | mriedem | dansmith: i haven't read it but what's the difference? you mean making the api capability separate which is what, a microversion and a min compute service version compat check? | |
| 17:02:22 | dansmith | mriedem: not even a min version check I think, a compute capability check | |
| 17:02:47 | mriedem | so the api checking the resource provider traits? | |
| 17:03:13 | dansmith | er, maybe I'm confused, I thought the api could check the compute capabilities, but maybe that's stupid | |
| 17:03:25 | dansmith | so yeah maybe a version check and a cap flag in the compute manager | |
| 17:03:52 | mriedem | i've brought up that idea before about the api checking compute capabilities via traits, e.g. https://review.opendev.org/#/c/666604/ | |
| 17:03:52 | dansmith | mriedem: point being, lyarwood had it in his now-abandoned first rev to remove that api check, and his current spec says no API impact, so wondering which way you want to go | |
| 17:04:17 | mriedem | well there is obviously an api impact | |
| 17:04:39 | dansmith | mriedem: ...only if he removes that check in his series again | |
| 17:04:59 | dansmith | mriedem: and, you think that needs a microversion? just removing a check in some cases? | |
| 17:05:46 | mriedem | it's a behavior change that a user opts into, i.e. i can rescue volume-backed servers on cloud A but not cloud B, | |
| 17:05:49 | dansmith | if so, I understand why, but I don't have a good gut feeling for when we do and don't need to signal removing checks | |
| 17:05:50 | mriedem | which is usually a microversion | |
| 17:06:02 | dansmith | they can opt in but still refuse with the same error | |