| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-01-07 | |||
| 14:48:57 | artom | You can also force with live migration and an old microversion, yeah | |
| 14:49:18 | artom | "Prior to microversion 2.30, specifying a host will bypass validation by the scheduler, which could result in failures to actually migrate the instance to the specified host" | |
| 14:49:29 | artom | So you can live-migrate with 2.29 and the `host` argument | |
| 14:50:23 | EugenMayer | ok i have xena, that will not work. Is shelve to understood as i understand shelve in SCM tasks? Temporary stash away, get back? But basically that is nothing else then a glance op backing up the image, and then restoring it? | |
| 14:51:23 | EugenMayer | so shelve is somewhat a shortcut to backup / restore with a special image creating step and maybe a little more semantic - but technically glance image, then restore? | |
| 14:51:29 | artom | EugenMayer, you can use any older microversion with any newer cloud by passing --os-compute-api-microversion on the command line, so that's not the problem | |
| 14:52:16 | artom | The problem is that if you force a live migration to a host, you can end up with inconsistencies between what's in the database (request spec, specifically) and where the instance is actually running | |
| 14:52:22 | artom | Which could break future operations on it | |
| 14:52:34 | EugenMayer | artom ah yes, i could. What would you advice? Rather shelve unshelve? shelve would take 2x as long AFAIU since it will write to glance and read from there, why live is direct compute to compute, right? | |
| 14:52:37 | artom | EugenMayer, but to answer your question, yeah, your understanding of shelve is essentially correct | |
| 14:53:05 | artom | EugenMayer, forcing hosts with live migration is asking for trouble, do it in the properly supported way with shelve/unshelve | |
| 14:53:10 | lyarwood | EugenMayer: if you're using rbd as a backend it shouldn't take that long | |
| 14:53:43 | EugenMayer | i see. i just see that shelv is just creating an image in glance with -shelve as suffix | |
| 14:54:28 | EugenMayer | lyarwood: for me it's long due to the way i run glance (and where) but i guess that is just my burden. I think i can take the hit with the downtime without bigger issues. | |
| 14:54:57 | EugenMayer | A little comment on the part with the live migration, am i understanding it right that it would happen compute to compute, not going over glance? | |
| 14:55:35 | artom | Correct | |
| 14:55:55 | EugenMayer | oh damn, shelve in the GUI is non interactive, it just uses the old host. Hehe, onde again i guess :) | |
| 14:56:34 | EugenMayer | artom and lyarwood - thank you for your insight! Super helpful. | |
| 14:58:10 | artom | lyarwood, since you seem to be about - did you put up any code for ephemeral disk encryption, btw? I read through the spec, was looking to read through the patches | |
| 15:07:51 | lyarwood | artom: https://review.opendev.org/q/topic:%22change-760456-2%22+(status:open%20OR%20status:merged) is the old topic from a year ago, I've got rebased things locally that I'll push up next week and talk you through | |
| 15:24:08 | EugenMayer | is there any way to see the progress of a live migration? | |
| 15:24:24 | EugenMayer | like an estimation or how much data has been transmitted? | |
| 15:30:32 | lyarwood | EugenMayer: https://docs.openstack.org/nova/latest/admin/live-migration-usage.html#monitoring-the-migration | |
| 15:31:54 | EugenMayer | thank you! | |
| 15:44:44 | EugenMayer | It seems after unshelving, availability_zone has been set, not availability_zone_hints - which now confuses my terraform. Is there a way to set the _hints one? AFAIR availability_zone is deprecated, right? | |
| 17:29:04 | opendevreview | Merged openstack/nova stable/xena: Reproduce bug 1953359 https://review.opendev.org/c/openstack/nova/+/820550 | |
| 20:32:29 | opendevreview | Merged openstack/nova stable/xena: Extend the reproducer for 1953359 and 1952915 https://review.opendev.org/c/openstack/nova/+/821941 | |
| 21:45:21 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: libvirt dom caps config: start supporting CPU die_id attrib https://review.opendev.org/c/openstack/nova/+/823865 | |
| 21:45:22 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: libvirt: build CPU distance matrix upon init https://review.opendev.org/c/openstack/nova/+/823866 | |
| #openstack-nova - 2022-01-09 | |||
| 14:12:59 | opendevreview | Lior Friedman proposed openstack/nova master: support use_multipath for nvme driver https://review.opendev.org/c/openstack/nova/+/823914 | |
| #openstack-nova - 2022-01-10 | |||
| 08:24:12 | opendevreview | Lior Friedman proposed openstack/nova master: support use_multipath for nvme driver https://review.opendev.org/c/openstack/nova/+/823941 | |
| 08:40:04 | opendevreview | Tobias Urdin proposed openstack/nova master: libvirt: Add announce-self post live-migration workaround https://review.opendev.org/c/openstack/nova/+/741529 | |
| 08:41:40 | opendevreview | Tobias Urdin proposed openstack/nova master: libvirt: Add announce-self post live-migration workaround https://review.opendev.org/c/openstack/nova/+/741529 | |
| 08:57:53 | bauzas | good morning Nova | |
| 08:59:55 | gibi | good morning | |
| 08:59:58 | gibi | I'm back | |
| 09:00:23 | gibi | please be gentle with me as I still needs to catch up | |
| 10:22:22 | bauzas | gibi: well, I'd say I'm all way meetings this week again :) | |
| 10:23:27 | bauzas | gibi: so I won't harass you *by now* | |
| 10:26:42 | gibi | bauzas: all way meetings sounds bad | |
| 10:27:41 | gibi | bauzas: do I need to ask for a spec freeze exception for https://review.opendev.org/q/topic:%22any-traits-support%22 ? | |
| 11:18:18 | gibi | OK, I saw the mail that the freez is moved to this week | |
| 11:20:22 | gibi | lyarwood: hi! do you have time to heck https://review.opendev.org/q/topic:any-traits-support spec before the spec freeze? (I'm hunting for a second core for it) | |
| 11:20:29 | gibi | *check | |
| 11:20:41 | lyarwood | gibi: ack queued | |
| 11:21:05 | gibi | thanks | |
| 12:02:11 | opendevreview | Merged openstack/placement master: Add yoga spec directory https://review.opendev.org/c/openstack/placement/+/819660 | |
| 13:57:51 | gibi | stephenfin: I've replied in https://review.opendev.org/c/openstack/oslo.messaging/+/819142/comment/b5b812b5_8091e77f/ but I'm not about your second comment | |
| 14:00:59 | gibi | * not sure | |
| 14:36:36 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | |
| 18:01:47 | sean-k-mooney | dansmith: so ya looking at the code its defintly an unintended consequence | |
| 18:01:58 | dansmith | yup | |
| 18:02:06 | sean-k-mooney | dansmith: i tought we were only checking for up sevice but its any service record | |
| 18:02:58 | sean-k-mooney | which results in the catch 22 of you cant start the conductor to be able to udpate the computes in the db | |
| 18:04:04 | sean-k-mooney | well unless service.get_minimum_version_all_cells is ignoreing down computes but i dont think it is | |
| 18:06:31 | sean-k-mooney | actully | |
| 18:06:32 | sean-k-mooney | https://github.com/openstack/nova/blob/4a359d576ddbc4b104116515c7e8b4176ac511f7/nova/db/main/api.py#L403-L412 | |
| 18:06:56 | sean-k-mooney | its not chekc up or down but is checking forced down | |
| 18:07:17 | sean-k-mooney | so the workaorund would have been to force them down before the upgrade | |
| 18:08:04 | sean-k-mooney | and the fix would be to allow filtering based on current state | |
| 18:08:21 | sean-k-mooney | or somethign like that | |
| 18:11:40 | dansmith | yeah, makes sense | |
| 18:11:44 | dansmith | also, | |
| 18:12:00 | dansmith | if you have one compute that was never upgraded and you forgot about (has been off for a year) you wouldn't want to hold up the upgrade until you find it | |
| 18:19:32 | opendevreview | Jonathan Race proposed openstack/nova-specs master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/nova-specs/+/824044 | |
| 18:36:56 | opendevreview | Artom Lifshitz proposed openstack/nova master: WIP: libvirt: remove default cputune shares value https://review.opendev.org/c/openstack/nova/+/824048 | |
| 19:10:44 | opendevreview | Jonathan Race proposed openstack/os-traits master: Adds Pick guest CPU architecture based on host arch in libvirt driver support https://review.opendev.org/c/openstack/os-traits/+/824050 | |
| 19:26:21 | artom | So if Jonathan Race writes an `if` block, is that a race condition? :D | |
| 19:27:20 | chateaulav | -lol, its a fast one for sure | |
| 19:30:36 | kashyap | chateaulav: Hey, I saw your email, but glad you're already here chatting. (I'm just back and catching up with things) | |
| 19:35:34 | opendevreview | Kashyap Chamarthy proposed openstack/nova-specs master: Repropose "CPU selection with guest hypervisor consideration" https://review.opendev.org/c/openstack/nova-specs/+/824053 | |
| 19:36:43 | kashyap | artom: In case you have a bit of time, mind you mind looking at chateaulav (Jonathan Race's) spec/blueprint? He has already been on it before I went on PTO | |
| 19:38:08 | artom | kashyap, wait, can you clarify? That spec is jut for the automatic re-approval paperwork, right? | |
| 19:38:15 | kashyap | artom: Mine, yes | |
| 19:38:26 | kashyap | artom: I was referring to chateaulav's spec - https://review.opendev.org/c/openstack/nova-specs/+/824044 | |
| 19:38:37 | kashyap | "Adds Pick guest CPU architecture based on host arch in libvirt driver support" | |
| 19:38:42 | artom | Ah, sorry, got confused by the "CPU" in both | |
| 19:39:26 | artom | Ack, I can take a look | |
| 19:39:41 | kashyap | chateaulav notes he's got a preview version of the code. | |
| 19:40:16 | kashyap | chateaulav: Also, I must add, upstream has been severely starved of reviewer attention, so don't be dissuaded if you don't see "quick responses". A ping here can help. | |
| 19:40:37 | kashyap | artom: Yeah, not your fault; a quick look at the title can be deceiving :) | |
| 19:40:59 | chateaulav | no worries, i understand. :) | |
| 19:46:34 | sean-k-mooney | kashyap: did you reporpose that based on the xena version | |
| 19:52:04 | sean-k-mooney | dansmith: i havent read your review comments on the health check speck but ill try and rework it tommorw with the other feedback | |
| 19:52:31 | dansmith | sean-k-mooney: cool, looks very comprehensive :) | |
| 19:54:00 | sean-k-mooney | am i was considering punting warn out of the inital scope | |
| 19:54:18 | sean-k-mooney | do you think we shoudl try and keep it intiall or just start with pass/fail | |
| 19:55:00 | dansmith | I think pass/fail for first go seems fine.. we can keep it in the spec as a valid result, but just implement everything as pass/fail initially I think | |
| 19:55:33 | sean-k-mooney | ack. i was conidering moving it to the alternitives section but that works too | |
| 19:56:05 | dansmith | if we're going to have it, it's not really an alternative, so I'd just leave the door open but say initially we'll just target pass/fail for the actual implementaiton | |
| 19:56:19 | sean-k-mooney | ack | |
| 19:57:13 | sean-k-mooney | and yes i speelchecked v2 with gramerly but then i made a lot of changes i will corret that in v4 | |
| 19:57:59 | dansmith | I figured.. seemed like a whole section was affected :D | |
| 19:59:05 | sean-k-mooney | oh i like the idea of makeing devstack use this to see if the service is started | |
| 19:59:16 | dansmith | yeah, dogfood is yummy :) | |
| 19:59:34 | sean-k-mooney | your right we currently hit the service endpoitn and check if its up | |
| 19:59:44 | dansmith | yeah | |
| 20:00:42 | sean-k-mooney | ok its just 8 hear so ill call it a day. hope you enjoyed your PTO talk to you tommorow | |
| 20:00:48 | sean-k-mooney | o/ | |
| 20:01:02 | dansmith | o/ | |