Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-08-02
11:54:53 gibi sean-k-mooney[m]: locally this works ^^ lets see if it passes tempest and grenade
11:55:05 gibi dansmith_: meanwhile with sean-k-mooney[m] we figured a solution for my question ^^
12:07:07 artom gibi, I have a concern on https://review.opendev.org/c/openstack/nova/+/851832 - does it sound legit to you? I'm not too sure myself...
12:55:01 opendevreview Merged openstack/nova master: [docs] Fix mention of custom scheduling after Wallaby https://review.opendev.org/c/openstack/nova/+/851807
12:55:26 opendevreview Guillaume Espanel proposed openstack/nova master: Skip useless qemu-img convert when snapshotting https://review.opendev.org/c/openstack/nova/+/851854
13:00:10 gibi artom: you and sean-k-mooney[m] both raised this, I'm waiting for grenade to prove that it is a real problem or not. If it is then the only way to keep this work is to decorate save() to modify it so the name is kept.
13:00:41 gibi I'm not sure how the names of the RPC is mapped
13:01:03 gibi in you example you need an old conductor
13:01:17 gibi but I think we say, upgrade your control service first
13:01:28 sean-k-mooney gibi: dansmith_ might be able to help you figure that out but i can point to where that is done of the top of my head
13:01:31 gibi so in theory the conductor will have both save and _remote_save
13:01:47 gibi during a rolling upgrade
13:01:56 gibi old computes will call save over RPC and that exists
13:02:08 gibi new computes probably will call _remote_save and that also exists in a new conductor
13:02:24 gibi sean-k-mooney: ack
13:23:25 artom gibi, for a major version upgrade, yeah, control tier first, so it's not a problem
13:23:31 artom It's only a problem if we backport
13:23:43 sean-k-mooney[m] my laptop over heated again
13:24:21 sean-k-mooney[m] ill be upstream only for a bit while it cools down and i get the vpn set up elsewhere
13:25:03 artom Pour mineral oil in your bathtub and dunk your laptop in there?
13:28:48 gibi artom: hm, if we backport then both the old and the new side will have both save and _remote_save so I don't see the problem about the backport either
13:29:26 opendevreview Radosław Piliszek proposed openstack/nova stable/yoga: [docs] Fix mention of custom scheduling after Wallaby https://review.opendev.org/c/openstack/nova/+/851870
13:32:11 opendevreview Balazs Gibizer proposed openstack/nova master: Remove double mocking https://review.opendev.org/c/openstack/nova/+/851445
13:32:11 opendevreview Balazs Gibizer proposed openstack/nova master: hacking: force explicit import of python's mock https://review.opendev.org/c/openstack/nova/+/708768
13:32:12 opendevreview Balazs Gibizer proposed openstack/nova master: Remove the PowerVM driver https://review.opendev.org/c/openstack/nova/+/850346
13:33:52 kashyap gibi: Thx for cleaning up the PowerVM!
13:34:00 gibi that wasn't me
13:34:03 gibi I just rebased
13:34:09 kashyap Err, stephenfin++ :)
13:34:23 kashyap What a diffstat: +10 -9350
13:45:39 dansmith_ artom: gibi sean-k-mooney[m]: I'm really -2 on that approach in general, but -1 for politeness
13:46:17 opendevreview Elod Illes proposed openstack/nova stable/train: DNM: test preinstall of python3-yaml https://review.opendev.org/c/openstack/nova/+/851861
13:46:32 dansmith_ gibi: to answer your question, the methods are mapped automatically, which means it's a problem for minor and major upgrades as artom noted, and why you can't find the method mapping
13:46:48 gibi dansmith: thanks for the feedback
13:48:08 gibi dansmith: so during minor upgrade we allow new compute code to run before the conductor is upgraded?
13:48:27 dansmith yes, any service in any order
13:49:03 gibi that is news for me
13:49:08 gibi anyhowe
13:49:18 dansmith but as I said on the review, this is really an impedance mismatch between compute and manager, it sounds like, and some refactoring there needs to happen instead of doubling down on the original thing, IMHO
13:49:30 dansmith gibi: okay, that's why artom specifically called out minor updates
13:49:58 dansmith basically, we expect anyone should be able to "yum upgrade" on any node at any time
13:50:11 gibi ack, I learned something new today
13:50:16 gibi going back to the original problem
13:51:00 gibi I don't know what will break if we remove the mutated migration context from the rollback_live_migration_at_destination call
13:51:26 gibi It was added there on purpose as far as I see
13:51:51 artom Yeah, it was so that we roll back the stuff claimed on the destination
13:51:54 dansmith it's something in driver.destroy() that looks to see if there's a migration context, and does more/less stuff during destroy as a result right?
13:52:19 artom Actually, maybe not, ignore me until I look at the code again
13:52:53 dansmith as noted, I think that was probably the first bad move
13:53:06 dansmith the "temporarily mutate instance so I don't have to change code elsewhere"
13:53:23 dansmith ended up having a side-effect that we didn't expect, so more flags to prevent side effects is just compounding the problem :)
13:55:00 gibi dansmith: I agree with general idea not to add more flags. So lets see if we can figure out how to untangle what we have
13:55:07 dansmith ++
13:58:12 gibi dansmith: if we are already at the problem the follow up patch https://review.opendev.org/c/openstack/nova/+/850746/3 show another occurence of the save under mutated migration context codepath.
13:58:21 gibi we call driver.rebuild https://review.opendev.org/c/openstack/nova/+/850746/3 under a mutated context
13:58:24 kashyap gibi: Hey, is there some "openstack server show" command to see the machine type configured on the compute node? Or 'grep'ing the nova.conf / `sudo virsh dumpxml $instance` the only way?
13:58:59 dansmith gibi: I have to jump on a call, might have a few minutes after before the next one at the top of the next hour
13:59:01 gibi and ironic virt driver saves the instance https://review.opendev.org/c/openstack/nova/+/850746/3
13:59:01 bauzas kashyap: you would need to be an admin at least if so
13:59:09 gibi dansmith: ack
13:59:15 gibi dansmith: no worries
13:59:19 kashyap bauzas: Right, let's say admin. Is there an admin Nova command?
13:59:31 bauzas this is a conf opt
13:59:43 bauzas so this shouldn't be an API extension
14:00:21 bauzas in general, we don't want to provide an API for knowing about some config option
14:00:56 kashyap bauzas: Right; fair enough
14:01:49 kashyap bauzas: Note, this is also a metadata and extra_spec property as well
14:01:57 kashyap "this" == guest machine type
14:03:47 kashyap bauzas: So if a user configures a Glance image with that image meta property, they should be able to see
14:05:38 kashyap bauzas: So, `openstack image show` should show it if a user sets it
14:06:33 gibi dansmith: so if you have a minute at some point I summarized my second question here https://review.opendev.org/c/openstack/nova/+/850746/3/nova/compute/manager.py#3797
14:06:52 opendevreview Elod Illes proposed openstack/nova stable/train: DNM: test preinstall of python3-yaml https://review.opendev.org/c/openstack/nova/+/851861
14:08:53 gibi kashyap: while I understand the need to see what machine type an instance uses, I don't think we have a single place we persist it for the insance. I guess we rely on the fact that we can always regenerate the machine type from the flavor + image + compute config.
14:09:28 kashyap gibi: Great answer; that's exactly what I'm writing for a (downstream) docs question
14:09:48 kashyap It is set via 3 places as you indicate - per-compute host config; flavor extra spec; or an image metada prop
14:09:53 kashyap s/metada/metadata/
14:16:55 kashyap gibi: Oh, wait - do we actually support this hw:machine_type" via flavor extra_spec?
14:21:38 gibi kashyap: I dont see machine_type in https://docs.openstack.org/nova/latest/configuration/extra-specs.html
14:21:55 kashyap gibi: Yeah, me neither: so only two ways - compute config; or image meta
14:22:52 kashyap gibi: For image, a tenant user should be able to see it via `openstack image show`, right?
14:23:05 gibi I think so
14:25:18 gibi kashyap: one thing i see is that nova stores the image meta in instance.system_metadata['image_hw_machine_type'] so that even if the image is changed later the instance has its machine type persisted
14:25:59 kashyap Yeah, we do store it in system_metadata (Lee did that work)
14:26:07 gibi also if an admin want to query the machine_type of an instance then it can be done via nova-manage
14:26:08 kashyap https://docs.openstack.org/nova/latest/admin/hw-machine-type.html
14:26:29 gibi ack, that is the one
14:26:30 kashyap gibi: What about the tenant user? (Perhaps via `openstack image show`?
14:27:10 gibi openstack image show only valid the the image properties are not changed after the instance is booted (I'm not sure the image meta could change)
14:27:27 bauzas oh the q35 saga
14:27:31 bauzas forgot about it
14:27:41 bauzas hence the nova-manage command
14:27:59 bauzas actually, 4 given I reply
14:28:02 kashyap gibi: Oh, right: "nova-manage image_property show $instance_uuid $property"
14:28:28 kashyap --^ The above is for tenant too, right?
14:29:18 kashyap So, it'd be: `nova-manage image_property show $instance_uuid hw_machine_type`
14:31:16 gibi the tenant does not have access to nova-manage
14:31:23 gibi that is an admin tool
14:31:26 gibi afaik
14:31:33 kashyap Yes, you're right
14:39:59 opendevreview Stanislav Dmitriev proposed openstack/nova master: Add support for sync writes with block migration https://review.opendev.org/c/openstack/nova/+/851892

Earlier   Later