| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-01-13 | |||
| 10:34:06 | gibi | brinzhang, alex_xu: responded in https://review.opendev.org/c/openstack/nova/+/729563 (finally) | |
| 10:34:47 | openstackgerrit | Kashyap Chamarthy proposed openstack/os-traits master: Add a trait for UEFI Secure Boot support https://review.opendev.org/c/openstack/os-traits/+/770570 | |
| 10:42:01 | openstackgerrit | Stephen Finucane proposed openstack/python-novaclient master: Add support for microversion v2.88 https://review.opendev.org/c/openstack/python-novaclient/+/770573 | |
| 10:49:35 | brinzhang | gibi: so we wont merge this patch, right? | |
| 11:46:55 | gibi | brinzhang: we need a separate bugfix, that is all what I said | |
| 11:48:09 | brinzhang | IMO, the bug fix shuold not prevent this patch go | |
| 11:48:30 | brinzhang | we shuold register a bugfix, and then fix it | |
| 11:51:58 | gibi | brinzhang: yepp, that works for me | |
| 11:53:23 | brinzhang | gibi: thanks, I hope we can make this patch merge, it's also meet alex_xu's meaning | |
| 12:26:35 | sean-k-mooney | lyarwood: i know the image metadata is in the instance_system_metadata table | |
| 12:26:52 | sean-k-mooney | lyarwood: thats why i wanted you to set the value there | |
| 12:27:08 | sean-k-mooney | they are just prefixed with img_ | |
| 12:27:50 | lyarwood | sean-k-mooney: ah I thought you were also suggesting that we dump all of the image metadata props in there as well | |
| 12:28:06 | lyarwood | sean-k-mooney: I just missed that they were there already, prefixed by image_ as you said | |
| 12:28:47 | sean-k-mooney | yeah so i was suggesting setting the effective values of all image props there instead of just the set values | |
| 12:29:12 | sean-k-mooney | e.g. if you dont have hw_vif_model set today it will normally default to virtio | |
| 12:29:40 | lyarwood | ah right | |
| 12:29:41 | sean-k-mooney | so we woudl store img_hw_vif_model=virtio | |
| 12:29:46 | sean-k-mooney | or whatever it is | |
| 12:29:58 | sean-k-mooney | as if it had been set | |
| 12:30:04 | lyarwood | FWIW I'm not overwriting image_hw_machine_type at the moment | |
| 12:30:18 | lyarwood | I'm just dumping it into hw_machine_type | |
| 12:30:43 | sean-k-mooney | ya you could do that the only issue with that approch is you have to now check both in the code | |
| 12:30:43 | lyarwood | image_hw_machine_type just remains on the original value | |
| 12:31:13 | sean-k-mooney | well if image_hw_machine_type was set tehn you would not be settting hw_machine_type | |
| 12:31:32 | sean-k-mooney | since you only need to set that if the machine type is not set in the image | |
| 12:31:59 | lyarwood | it's just copied from image_meta in that case | |
| 12:32:15 | sean-k-mooney | yep | |
| 12:32:26 | sean-k-mooney | i was trying to avoid having two sources of truth | |
| 12:32:37 | sean-k-mooney | e.g. image_hw_machine_type and hw_machine_type | |
| 12:33:10 | lyarwood | image_hw_machine_type is just the original, hw_machine_type is the single source of truth from now on | |
| 12:33:26 | lyarwood | as we can change it over time etc | |
| 12:33:37 | sean-k-mooney | well no we cant thats the point | |
| 12:33:44 | sean-k-mooney | if its set in the image it cant be changed | |
| 12:33:46 | lyarwood | you can through the versioned machine types | |
| 12:34:03 | sean-k-mooney | no if its set in the image thats it we dont use the config values at all | |
| 12:34:47 | lyarwood | why? moving forward through the versioned machine types provides a stable ABI etc | |
| 12:35:05 | sean-k-mooney | it would break backwards compatiablity with teh existing usage | |
| 12:35:13 | lyarwood | how? | |
| 12:35:17 | kashyap | Yes to what lyarwood said on versioned machine types | |
| 12:35:40 | kashyap | sean-k-mooney: When talking of this topic, a clear example would make sure we're not talking of different things. | |
| 12:35:42 | sean-k-mooney | the existing usage is that if yuou set a version machine type in the image metadata it will have that version for the lifetime of the instance | |
| 12:35:57 | sean-k-mooney | if you set the unversion on then it will use the latest version on the host it spawns on | |
| 12:36:18 | sean-k-mooney | we should not be changing that behavior in your spec | |
| 12:36:51 | lyarwood | the only part I'm changing is that instead of being for the lifetime of the instance operators can now update the versioned machien type | |
| 12:37:17 | lyarwood | aliases from the image would stay, I don't switch them out for the versioned machine types etc | |
| 12:37:34 | sean-k-mooney | lyarwood: that was not part of the spec | |
| 12:38:02 | sean-k-mooney | we did not provide any mechanium to update the machine type over the instacen lifttime | |
| 12:38:14 | sean-k-mooney | that is what the recreate api would provide | |
| 12:39:01 | lyarwood | that's between types, why would we ask users to rebuild for a version update? | |
| 12:39:08 | sean-k-mooney | operators could alwasy update the versioned machine type by updating the config for instance that dont have hw_machine_type set | |
| 12:39:12 | lyarwood | and I'm pretty sure it's in the spec | |
| 12:40:18 | sean-k-mooney | lyarwood: recreate with the same image and flavor was ment to just update the metadata its not the same as rebuild in that case | |
| 12:40:53 | lyarwood | sean-k-mooney: ah sorry you're talking about an API that doesn't exist :) | |
| 12:41:28 | sean-k-mooney | yes the part that was defered/rejected at the ptg meaning we had no aggreaded way to update the machine type | |
| 12:41:33 | lyarwood | sean-k-mooney: and I agree that would be nicer and would mean we wouldn't need a nova-manage command for this | |
| 12:43:04 | sean-k-mooney | ya so in the spec the only way to change the machine type is via the nova manage command | |
| 12:43:19 | openstackgerrit | Vlad Gusev proposed openstack/nova stable/victoria: Use subqueryload() instead of joinedload() for (system_)metadata https://review.opendev.org/c/openstack/nova/+/761809 | |
| 12:43:25 | sean-k-mooney | but the image metadata still has precidence | |
| 12:43:34 | sean-k-mooney | so it only matters for vms without that | |
| 12:51:12 | openstackgerrit | Brin Zhang proposed openstack/nova master: Replaces tenant_id with project_id from Flavor Access APIs https://review.opendev.org/c/openstack/nova/+/767704 | |
| 12:54:54 | brinzhang | bauzas: do you have time to check my response of your comments in https://review.opendev.org/c/openstack/nova/+/729563, there is -1 on it | |
| 12:55:42 | brinzhang | bauzas: may it will take your some time, but whatever thanks | |
| 13:31:10 | bauzas | brinzhang: ack, will look at your replies then | |
| 14:44:02 | openstackgerrit | Takashi Natsume proposed openstack/python-novaclient master: Deprecate agent commands and APIs https://review.opendev.org/c/openstack/python-novaclient/+/769068 | |
| 16:19:12 | melwitt | stephenfin, artom: would like to have your numa expert review on this patch (and the func test below it) please if you could spare some time this week https://review.opendev.org/c/openstack/nova/+/769614 | |
| 16:19:50 | artom | melwitt, will take a look tomorrow | |
| 16:20:03 | melwitt | thanks! | |
| 16:20:20 | artom | Hopefully before then, actually | |
| 16:29:51 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP libvirt: Record the machine_type of instances in system_metadata https://review.opendev.org/c/openstack/nova/+/767533 | |
| 16:29:55 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP nova-manage: Add commands for managing instance machine type https://review.opendev.org/c/openstack/nova/+/769548 | |
| 16:29:57 | openstackgerrit | Lee Yarwood proposed openstack/nova master: WIP nova-status: Add hw_machine_type check for libvirt instances https://review.opendev.org/c/openstack/nova/+/770643 | |
| 16:56:44 | sean-k-mooney | artom: i havenet made any changes yet but i responed to your questions in https://review.opendev.org/c/openstack/nova-specs/+/764999/2/specs/wallaby/approved/libvirt-vdpa-support.rst can you re review | |
| 16:57:09 | sean-k-mooney | i have some WIP patches up as well https://review.opendev.org/q/topic:%22vhost-vdpa%22+(status:open%20OR%20status:merged) | |
| 16:57:27 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM try to replace retry with libvirt event in detach https://review.opendev.org/c/openstack/nova/+/770246 | |
| 16:57:45 | sean-k-mooney | its not fully complete as i still need to extend the pci tracker and where we create the pci request | |
| 16:58:01 | sean-k-mooney | and i need to test it locally and write tests and docs | |
| 16:58:28 | sean-k-mooney | but it has the outline of about 2 thirds of the code | |
| 16:59:26 | artom | sean-k-mooney, cool - I want to un-WIP my socket affinity spec, then I'll take a look | |
| 17:10:04 | markguz_ | Hi nova folks. THe good people at #openstack-ironic thought it might be a good idea for me to ask about my problem here. | |
| 17:12:04 | markguz_ | I've got an issue where my ironic instance spawning is getting stuck for +/- 10mins just after i start deployment. The nova-scheduler picks the correct compute node and then the nova-compute node reports "Starting instance... _do_build_and_run_instance" | |
| 17:12:40 | markguz_ | then nothing happens for about 10 mins. then suddenly the process starts and deployment continues.. | |
| 17:13:30 | markguz_ | TheJulia over at ironic thinks that the process is getting stuck at the scheduling stage. The vm reports Building, but the task status sits at "none" during that 10mins | |
| 17:14:43 | markguz_ | For VMs there is no delay, only for BMs. This is Rocky. and it is not a busy deployment. Very little activity going. We can go days without spawning bm or vm instances | |
| 17:15:35 | markguz_ | I've been trying to dig around the code to see what happens when the compute node reports "Starting instance... _do_build_and_run_instance" but it's very hard to follow | |
| 17:16:43 | markguz_ | If anyone could help me follow the rabbit through the rabbit hole and see exactly what is happening, I'd be most appreciative | |
| 17:23:58 | melwitt | markguz_: if it's landed on the compute node already, we don't consider that to be "scheduling" as it's already been scheduled/placed. but to dig into this further you'll want to trace the request id of the line that says "Starting instance" in the nova-compute log and see if you can see where it stops making progress. that would help | |
| 17:25:31 | sean-k-mooney | if this is ironic by they way whe n we get do do_build_and_run_instance at some point the compute manager will hand of to the ironic driver which will call ironic to provision the node | |
| 17:26:27 | melwitt | right. would want to look and see if he can verify it's gotten to that point | |
| 17:26:58 | sean-k-mooney | https://opendev.org/openstack/nova/src/branch/master/nova/compute/manager.py#L2186 starting to build instance is right at the top | |
| 17:27:31 | sean-k-mooney | the we save the task state at None and vmstate building | |
| 17:27:41 | melwitt | yeah, I know. just saying he can trace the request id to see how far it gets | |
| 17:27:54 | melwitt | after that | |
| 17:29:09 | markguz_ | here's a grep of the req id for an instance out of the logs http://paste.openstack.org/show/801601/ | |
| 17:29:44 | markguz_ | nothing between 9.40 and 10.05 | |
| 17:31:14 | sean-k-mooney | do you have the concurnet build limit set | |
| 17:31:15 | stephenfin | melwitt: Comments left | |
| 17:31:17 | stephenfin | sean-k-mooney: ^ | |
| 17:31:20 | sean-k-mooney | for the compute service | |
| 17:31:26 | sean-k-mooney | it defaults to 10 i belive | |