Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-09-10
15:24:11 gibi it is not visible in https://zuul.openstack.org/builds?project=openstack%2Fplacement&pipeline=periodic-weekly so it happened in the last ~5 days
15:26:11 gibi hm, the global req bumped oslo.db to 11.0.0 two days ago, that is a likely candidate
15:28:54 melwitt agree. aside, there likely isn't a cross-placement job on global bump. I wonder if we should add one
15:31:17 gibi OK I confirmed that those tests fail with oslo.db 11.0.0 but passing with oslo.db 10.0.0 (the previous version)
15:31:42 gibi yeah I don't think we have a placement functional job on the global req repo
15:31:43 sean-k-mooney i dont see one in https://github.com/openstack/requirements/blob/master/.zuul.d/cross-jobs.yaml
15:31:46 gibi but we should
15:32:22 sean-k-mooney we have a nova one but you are correct no placment one https://github.com/openstack/requirements/blob/master/.zuul.d/project.yaml#L42
15:58:37 gibi ok I failed to figure out how to reformulate those tests with the new sqlalchemy and I have to drop soon. sorry
15:59:21 melwitt thanks gibi. I'm also trying to fix, will let you know if I find any success
15:59:30 gibi thanks
15:59:35 gibi and good luck
15:59:53 melwitt thanks. have a nice weekend o/
16:00:36 gibi same to you too eventually o/
16:01:08 melwitt :)
16:03:12 opendevreview Artom Lifshitz proposed openstack/nova master: WIP: Gracefully power off guest on instance delete https://review.opendev.org/c/openstack/nova/+/808474
16:29:04 sean-k-mooney artom: ok so that jsut add a call self._power_off_instance
16:29:15 sean-k-mooney are you sure we cant remove self._shutdown_instance(context, instance, bdms)
16:29:36 artom sean-k-mooney, maybe? Seems it does more than just power if off though...
16:31:53 sean-k-mooney it delete the volume attachments and detory the domain xml
16:31:58 sean-k-mooney that seam to be about it
16:32:09 sean-k-mooney presumable _cleanup_volumes would do the same
16:32:33 sean-k-mooney ok _cleanup_volumes does not handel the attachments
16:32:46 sean-k-mooney or calling terminat_connection
16:32:49 sean-k-mooney what about powerofof
16:32:52 artom lulz we just suck at reusing code, do we?
16:33:45 sean-k-mooney poweroff instance just calls driver.power off
16:34:11 sean-k-mooney what we proably shoudl do is remove the call to driver.destry in self._shutdown_instance
16:34:21 dasm hey team. i'm trying to wrap my head around placement for nova. When VCPUs number are changed? When VM is stopped? Or only when deleted? I found this old thread: http://lists.openstack.org/pipermail/openstack/2014-June/008022.html but not sure if it's still valid.
16:34:22 sean-k-mooney and have it call _power_off_isntace
16:35:42 artom sean-k-mooney, yeah, maybe. One thing I don't like about my current (admitedly very quickly hacked up) thing is that we're leaking libvirt driver stuff into the compute manager
16:35:56 artom Though I guess it *kinda* makes sense?
16:36:14 opendevreview melanie witt proposed openstack/placement master: Call Engine.execute() in func tests for oslo.db 11.0.0 https://review.opendev.org/c/openstack/placement/+/808477
16:36:26 artom One _power_off_instance() is graceful shutdown, _shutdown_instance() pulls the plug.
16:36:33 artom That's not really driver-specific...
16:36:59 sean-k-mooney and they are reverst in libvirt too
16:37:06 sean-k-mooney poweroff with virsh pulls the plug
16:37:15 sean-k-mooney if i rememebr correctly
16:37:39 sean-k-mooney i think you can just call power_off here https://github.com/openstack/nova/blob/e276184892250922c96c38415eabbaf7507f7e17/nova/compute/manager.py#L2897-L2898
16:37:51 artom y haev clear werd wen complixaeted werds maek tings moar fun
16:37:59 sean-k-mooney becasue it will call driver.destroy if the gracefull approch does not work right
16:39:54 artom I think so? _power_off_instance() does the timeout calc for us...
16:40:41 sean-k-mooney yes
16:40:55 sean-k-mooney https://github.com/openstack/nova/blob/e276184892250922c96c38415eabbaf7507f7e17/nova/compute/manager.py#L2833-L2850
16:41:14 sean-k-mooney huh apparently that is setabel in the image
16:41:29 artom Fun surprises every day
16:41:41 sean-k-mooney that is also not the correct way to get image properties
16:41:45 sean-k-mooney i mean it works
16:41:54 sean-k-mooney but we shoudl be using hte objects
16:42:52 sean-k-mooney oh i see why its not useing the object
16:42:56 sean-k-mooney its not in the object
16:43:45 sean-k-mooney so image_os_shutdown_timeout or os_shutdown_timeout is not a legal image property
16:43:46 artom At this point in the rabbit hole we're going to poke out in Australia
16:44:10 sean-k-mooney this is just code form before we made the image props ovos
16:44:16 kashyap artom: I politely "well-actuallyed" (I strongly avoid this) here on destroy() behaviour: https://review.opendev.org/c/openstack/nova/+/808474. Hope you don't mind. :)
16:44:18 sean-k-mooney that was likely an extenion
16:44:40 kashyap artom: But your broader goal is a good catch -- with volumes, i.e
16:45:38 artom kashyap, valid points
16:45:48 artom Well, I guess you're heading out, will continue in the review
16:46:06 sean-k-mooney artom: care to add a todo to remove supprot for image_os_shutdown_timeout or add it to the image proprties properly in the future
16:46:26 artom sean-k-mooney, sure, just stick it in gerrit please
16:57:20 sean-k-mooney artom: ok it should be all there
17:01:05 artom Cheers!
17:40:03 melwitt gibi: here's my patch for fixing the placement func test jobs https://review.opendev.org/c/openstack/placement/+/808477
17:49:19 dansmith melwitt: +2d that
17:49:30 dansmith melwitt: did the other thing to separate the transactions merge?
17:49:52 melwitt dansmith: no it's stuck behind this recent fail. I'm about to rebase onto ^
17:50:03 dansmith oh really, okay dang
17:50:06 melwitt also thanks for the +2
17:50:08 melwitt yeah :(
17:50:26 dansmith was going to say, we were still "recheck nova fail"-ing again yesterday
17:50:39 dansmith who else is around to slam this trivial fix in I wonder?
17:51:06 melwitt dansmith: yeah bauzas +W'ed earlier today (the transaction thing)
17:51:47 melwitt oh maybe gmann
17:52:15 melwitt gmann: are you around to review this gate fix for placement? https://review.opendev.org/c/openstack/placement/+/808477
17:52:30 dansmith ++
17:52:31 gmann melwitt: sure, checking
17:53:13 melwitt \o/
17:53:49 melwitt hm actually I'm not sure whether I will need to rebase on the fix. I get confused about whether/when zuul does it automatically
17:57:10 gmann melwitt: +A
17:57:36 melwitt gmann: thank you!! :)
17:58:05 dansmith melwitt: rebase.. rebase like the wind!
17:58:32 gmann dansmith: melwitt as it is different file it should not require rebase, and zuul should merge it once fix is merged
17:58:45 gmann we can try recheck once 808477 is merged
17:58:49 dansmith gmann: there's another fix that depends on this
17:59:04 dansmith rebase so we can make sure this lands before that
17:59:53 gmann 807014 this one ?
18:00:11 dansmith yeah
18:01:13 gmann I think 807014 should pass with recheck once 808477 is merged
18:01:57 dansmith right,
18:02:17 dansmith but 807014 is breaking lots of *other* gates, so we want that in the queue ASAP
18:03:20 gmann ohk.
18:03:47 gmann or try re/another +w can trigger gate pipeline directly ?
18:05:03 gmann but it might do check also. yeah rebase is more safer to put it queue asap
18:05:06 melwitt gmann: it's this if you want to try https://review.opendev.org/c/openstack/placement/+/807014
18:05:12 melwitt ok, will do then
18:05:24 dansmith I think rebasing is better,
18:05:34 dansmith because if they get kicked out, we want them to stay in the right order for the next trip
18:05:46 gmann ok
18:06:25 opendevreview melanie witt proposed openstack/placement master: Narrow scope of set allocations database transaction https://review.opendev.org/c/openstack/placement/+/807014

Earlier   Later