Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-10-09
10:31:56 sean-k-mooney actully that the set where is the get
10:32:03 lyarwood yeah
10:32:32 sean-k-mooney oh we just have it for set so when we build it we set it with the new name
10:33:03 sean-k-mooney the get is https://github.com/openstack/nova/blob/f24e054f5e41dcf45b7ecd20e6d41f4a293a91d2/nova/objects/image_meta.py#L657-L685
10:33:43 lyarwood but https://github.com/openstack/nova/blob/9fa563666e8500510def19269f740d99cab0e994/nova/compute/api.py#L841 is specifically using the older name so that's always None
10:34:36 sean-k-mooney so is if from here https://github.com/openstack/nova/blob/9fa563666e8500510def19269f740d99cab0e994/nova/compute/api.py#L843-L845
10:37:07 sean-k-mooney not looking at the img_mappings would be a bug unless we had an explict deprecation of this fucntionaliy
10:38:46 lyarwood I'm still not entirely sure what it is the dict provides tbh, looking for an example
10:39:02 lyarwood virtual image names to device names
10:40:13 sean-k-mooney i think you could pass anything you can pass in bdm on the commandline
10:41:18 lyarwood no that's stored in block_device_mapping or bdm_v2
10:41:42 lyarwood this is simple dict of things like {'root': '/dev/vda'} AFAICT
10:42:17 lyarwood https://github.com/openstack/nova/blob/4cf72ea6bfc58d33da894f248184c08c36055884/nova/block_device.py#L538-L588
10:42:45 sean-k-mooney i see in that case im less concerned
10:43:00 sean-k-mooney we dont provide stable/usersetable device names really anyway
10:43:59 lyarwood yup I wonder what this is actually used for tbh
10:44:41 sean-k-mooney https://github.com/openstack/nova/blob/f24e054f5e41dcf45b7ecd20e6d41f4a293a91d2/nova/objects/image_meta.py#L454-L460
10:46:31 sean-k-mooney it looks like it was never tested when we did the conversion
10:46:36 sean-k-mooney to ovos
10:47:15 lyarwood yeah we should get everything we need from img_block_device_mapping / block_device_mapping
10:48:35 openstackgerrit Lee Yarwood proposed openstack/nova master: compute: Lock by instance.uuid lock during swap_volume https://review.opendev.org/754695
11:24:19 openstackgerrit Lee Yarwood proposed openstack/nova master: Include removal of ephemeral backing files in the image cache manager https://review.opendev.org/689422
11:58:43 openstackgerrit Lee Yarwood proposed openstack/nova stable/ussuri: Use absolute path during qemu img rebase https://review.opendev.org/757083
11:59:07 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Use absolute path during qemu img rebase https://review.opendev.org/757084
11:59:28 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Use absolute path during qemu img rebase https://review.opendev.org/757085
12:48:00 openstackgerrit Stephen Finucane proposed openstack/nova master: docs: Add image metadata property reference guide https://review.opendev.org/756867
12:49:01 stephenfin lyarwood: Context on that img_mappings question was ^ I was trying to document what it was for and remove it if it wasn't necessary. I resorted to marking it as internal only and kicking the can down the road :-)
12:49:21 stephenfin though it sounds like you and sean-k-mooney might have teased it out, /me reads back up
12:50:08 lyarwood stephenfin: yeah tbh I don't think it's being used given what we were talking about above
12:50:10 lyarwood brb
12:51:31 stephenfin sean-k-mooney: I replied to your questions on that doc review. tl;dr: auto generating this stuff is too hard, and I'm not looking to replace Glance's XML schemas for code-based verification purposes
12:53:37 sean-k-mooney stephenfin:ya looking at the code we still have code to use the legacy name
12:53:59 sean-k-mooney however the data is nologer stored usign the legacy name so that code is dead
12:54:18 sean-k-mooney so i dont think img_mappins is used and we just use the image bdms
12:54:57 sean-k-mooney stephenfin: and ya i think if doc strings are not easy to use i guess doing it manually is ok
12:55:09 sean-k-mooney it would be nice if they could not get out of sync
12:55:56 stephenfin Agreed, but I just don't think it's practical in this case unfortunately
12:55:57 sean-k-mooney i would still like to encurage peopel to update glance whenever tehy add new image metadata
12:56:18 sean-k-mooney oh by the ay i also didnt repond to the pinning patch
12:56:32 sean-k-mooney yes i forgot we reused cpuset to avoid modifing the object
12:57:06 sean-k-mooney ill proably remove my -1 later just finishing up a bz comment beofre the bug call so havent got to reviews yet today
12:57:13 stephenfin cool
12:57:19 sean-k-mooney i saw your latest commnt in email however
13:09:10 lyarwood elod: huh weird, I was sure this landed in stable/victoria
13:09:16 lyarwood elod: thanks for catching that
13:10:04 openstackgerrit Lee Yarwood proposed openstack/nova stable/victoria: Use absolute path during qemu img rebase https://review.opendev.org/757098
13:10:22 openstackgerrit Lee Yarwood proposed openstack/nova stable/ussuri: Use absolute path during qemu img rebase https://review.opendev.org/757083
13:10:34 openstackgerrit Lee Yarwood proposed openstack/nova stable/train: Use absolute path during qemu img rebase https://review.opendev.org/757084
13:10:49 openstackgerrit Lee Yarwood proposed openstack/nova stable/stein: Use absolute path during qemu img rebase https://review.opendev.org/757085
13:16:28 elod lyarwood: np :)
13:28:16 CeeMac afternoon
13:28:52 CeeMac quick question, is there a way to set the libvirt cpu_mode using metadata or some such on a flavour/image/instance at all?
13:28:58 sean-k-mooney stephenfin: how would you feel about default all instance with a numa toplogy to hw:mem_page_size=small unless otherwise set. this is needed for numa in placment anyway but would you be open to doing this anyway even without numa in placment
13:29:49 sean-k-mooney we might want to restrict it to new instance only but we do have customer hit this edgecase a lot
13:30:44 sean-k-mooney the set hw:cpu_policy=dediecated and dont realise that unless they also set hw:mem_page_size=small then there vm will eventually get killed by the OOM reaper
13:31:11 sean-k-mooney since the vms memory is pined to a numa node but the did nto enable per numa memory tracking
13:33:07 sean-k-mooney stephenfin:by the way for your image properties patch should we send a mail to the list to let the glance folks know we are going to move documenation of image properties back into nova
13:43:07 stephenfin sean-k-mooney: I don't think an email is necessary. I'll just propose a patch to glance to remove the existing doc and point back to nova. If they want to keep their copy, that's fine
13:44:26 stephenfin sean-k-mooney: As for mem pages, I'm not sure. You can't overcommit with 'hw:mem_page_size' set, right? Even if you could, your overcommit would be against memory from that cell, rather than the entire host. Not necessarily a bad thing but both things are changes in behavior
13:47:01 sean-k-mooney right now it broken to not set it
13:47:29 sean-k-mooney we will use the global memory when determining if the vm wil fit then pin it to one numa node
13:47:49 sean-k-mooney so over commit is broken in any case
13:48:33 sean-k-mooney once we track numa in placment its not negoicable it has to do numa aware memroy tracking which is what setting that would do
13:48:50 sean-k-mooney we have had 2-3 customer hit this in the last year or so
13:51:47 sean-k-mooney for numa in placment this is adress by partioning the cloud into numa nost and non numa hosts.
13:52:32 sean-k-mooney we currently dont enforce that you se hw:mem_page_size if you have a numa toplogy but its always a bug/user errror to not set it
13:55:14 stephenfin if we can figure out a way to do overcommit on a per-node basis, then I'd be okay with that
13:55:21 stephenfin otherwise, it's a big change
13:56:30 sean-k-mooney well as is said overcomit does not work properly today
13:56:49 sean-k-mooney the OOM reaper will kill the vm if the numa node runs out of memory
13:56:56 sean-k-mooney even if the othe rnuma node is fully empty
13:57:21 stephenfin you could say the same thing about overcommit without NUMA
13:57:32 sean-k-mooney its not the same
13:57:45 stephenfin no, but it's similar
13:57:49 sean-k-mooney if you set over commit to 1.0 e.g. no over commit
13:58:04 sean-k-mooney with the current state the vms can be killed becuase the numa node is exausted
13:58:15 sean-k-mooney unless you set hw:mem_page_size=small
13:59:02 stephenfin yes, I understand that
13:59:03 sean-k-mooney its requried for numa in plamcent for numa hosts
13:59:18 sean-k-mooney for non numa hosts i was not going to be an issue since numa instance could not land there
13:59:33 stephenfin but if you had work and instances evenly distributed between NUMA nodes, then it would behave the same as the non-NUMA case
13:59:46 sean-k-mooney so we defered this conversation the last 2 cycles because numa in palcment will prevent it form happening
14:00:20 sean-k-mooney stephenfin: without my numa loadbancing feature it wont evenly disturbute
14:00:31 sean-k-mooney unless you consume all the cpus on the first node
14:00:39 sean-k-mooney even then it won evenly disturbute
14:02:25 openstackgerrit Dan Smith proposed openstack/nova master: Allow excluding image type capabilities https://review.opendev.org/756534
14:03:19 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _claim_pci_device_for_interface_attach to prepare for qos https://review.opendev.org/756895
14:03:20 openstackgerrit Balazs Gibizer proposed openstack/nova master: Make remove allocation symmetric with add allocation https://review.opendev.org/757110
14:03:20 openstackgerrit Balazs Gibizer proposed openstack/nova master: Allow extending an existing instance allocation https://review.opendev.org/757109
14:03:21 openstackgerrit Balazs Gibizer proposed openstack/nova master: Factor out port resource deallocation https://review.opendev.org/757111
14:07:29 openstackgerrit Balazs Gibizer proposed openstack/nova master: Support interface attach with qos ports https://review.opendev.org/756530
14:40:40 CeeMac any thoughts on if its possible to set the libvirt cpu_mode value against an image, flavour or instance?
15:03:50 sean-k-mooney CeeMac: its not possible and it was reject in both the image and flaovr in the past
15:04:16 sean-k-mooney CeeMac: we would prefer you to use traits to sate what instuctions you need instead
15:04:38 sean-k-mooney we will then schdule you to a host that has a cpu model that you can use
15:05:08 sean-k-mooney cpu_mode specificly is defined by the admin in the config and not overrideable because it has live migration implciations
15:06:13 CeeMac sean-k-mooney: thanks, I'm trying to expose hardware virtualization to a specific instance and didn't want to go down the line of making a global cpu_mode change
15:06:30 CeeMac sean-k-mooney: do you know which / if any specific traits would be avaialable to do that?
15:06:56 sean-k-mooney CeeMac: we intentionally dont expose this via a user or public api as its a interoperatblity issue and only applys to one virt dirver
15:07:27 sean-k-mooney CeeMac: do you mean nested virt e.g. expose vmx

Earlier   Later