Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-29
16:27:47 fwiesel Yes, sorry. I found a regression in our networking driver and fixed it. But there is another one.
16:28:26 fwiesel Some race-condition in the startup. I am optimistic that I can fix it this week.
16:28:46 fwiesel That's from my side. Back to you bauzas.
16:29:03 bauzas thanks
16:29:10 bauzas and good luck with the investigation
16:29:19 bauzas #topic Open discussion
16:29:48 bauzas just refreshed the page, nothing in there
16:29:53 bauzas so, anything anyone ?
16:30:37 tkajinam I've proposed oslo.utils release so we hopefully get it soon and can use it for some work in nova https://review.opendev.org/c/openstack/releases/+/933627
16:30:38 sean-k-mooney i tought there was somethign we said to cover in the meeting instead of the ptg
16:30:40 sean-k-mooney but i dont recall
16:30:43 tkajinam dansmith, ^^^ just fyi
16:30:47 dansmith tkajinam: thanks
16:30:52 bauzas tkajinam: thanks
16:31:05 tkajinam I'll work on https://bugs.launchpad.net/nova/+bug/2083518 once the release is created
16:31:52 sean-k-mooney i might be thinkign of https://review.opendev.org/c/openstack/nova-specs/+/932653 but i highlighted that in the cidner cross project
16:32:21 tkajinam sean-k-mooney, ah, yeah
16:32:23 bauzas yeah, we had no topics that were left to be discussed
16:32:26 sean-k-mooney tkajinam: you are porting that to oslo yes
16:32:40 sean-k-mooney and we will just consume the predecate form there once its released
16:32:49 tkajinam sean-k-mooney, yes. you are correct.
16:33:09 sean-k-mooney ya so i dont see anythign contoversion with that so im happy to review that when its ready
16:33:22 tkajinam :-)
16:34:13 tkajinam sean-k-mooney, talking about the spec you raised... I think you spotted a nice point and we need a new mechanism in cinder (qos specs which are not used by cinder but by nova during attachment)
16:34:43 tkajinam I overlooked the fact that the prpoosal is trying to use the existing qos specs but these are cinder internal one and can't be used by nova
16:34:47 sean-k-mooney well frontend qos policies are use by the hypervior (libvirt in this case)
16:35:03 sean-k-mooney to enforce it where as backend qos polcies are done on the stroage backend
16:35:04 tkajinam but that qos is associated with flavor, right ?
16:35:09 sean-k-mooney no
16:35:16 sean-k-mooney its assocated witht eh volume
16:35:30 sean-k-mooney we also have the ablity to do it via the flavor for nova created block devices
16:35:38 sean-k-mooney using the quota:* extra specs
16:36:12 sean-k-mooney i belive the current state is you can configure hard limits today
16:36:15 sean-k-mooney but not burst
16:36:27 sean-k-mooney and the brust limist are what they want to enabel
16:36:34 sean-k-mooney but that was my question to the cinder folk
16:36:50 tkajinam ok
16:36:51 sean-k-mooney to have them confirm what is and is not expected to be requestable vai cinder today
16:36:57 tkajinam I thought the qos specs are not propagated via connection info but it's set in storage backend
16:37:08 tkajinam I'll recheck it and fix my comments in that spec if needed
16:37:28 sean-k-mooney you set them on the voluem type and im not sure how they are propegated to nova
16:37:37 sean-k-mooney so this is where we need input form the cider folk
16:38:00 sean-k-mooney i.e are tehy on teh attachmetn? conection info? do we need to look them up ectra
16:38:05 bauzas can we end the meeting ?
16:38:12 sean-k-mooney yep i think so
16:38:15 tkajinam yeah we can discuss details in the spec
16:38:17 sean-k-mooney this can be an async dicussion
16:38:41 bauzas cool
16:38:46 bauzas then thanks all
16:38:49 bauzas #endmeeting
16:38:49 opendevmeet Meeting ended Tue Oct 29 16:38:49 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:38:49 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-29-16.00.html
16:38:49 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-29-16.00.txt
16:38:49 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-29-16.00.log.html
16:42:09 sean-k-mooney tkajinam: for what its worht i have only ever used cinder qos with ceph using the backend mode so i have nerver personally tried to use the frontend mode
16:42:16 sean-k-mooney i think you can use it with cinder-lvm
16:42:25 sean-k-mooney but im fuzzy on the details
16:43:45 sean-k-mooney thats a long way to say i think this coudl be configured and enabeld in tempest or whitebox tests and validated end to end in 1st party ci.
16:44:52 sean-k-mooney so im not really conserned about the testablity ro the libvirt xml generaion just the api contract between nova/cinder
16:46:11 sean-k-mooney i woudl hope the exisating cidner tempest plugins or core tempest could verify frontend qos and the proposer could jsut extend that (in adddtion to unit/fucntional tests)
16:46:15 tkajinam https://github.com/openstack/cinder/blob/master/cinder/volume/driver.py#L2698-L2756
16:47:15 tkajinam ahh, wait
16:47:16 tkajinam https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L1831-L1832
16:47:21 tkajinam ok I understand what you mean
16:48:00 sean-k-mooney right cinder has an enum https://github.com/openstack/cinder/blob/master/cinder/volume/qos_specs.py#L33 for diffent type of qos
16:48:34 sean-k-mooney and as you foudn the generic manager code shoudl include the qos if its front-end or both
16:48:58 sean-k-mooney it looks like its part of the connection info
16:49:16 sean-k-mooney in a optional qos_specs section
16:49:23 tkajinam yeah
16:49:42 sean-k-mooney looking at https://github.com/openstack/cinder/blob/master/cinder/volume/manager.py#L1836-L1839
16:50:00 sean-k-mooney im not sure they the burst values they are propsoing are supproted by cinder
16:50:16 sean-k-mooney so i think there shoudl be a cinder spec first to extend the set of qos types
16:50:23 sean-k-mooney and then we woudl just enable them
16:50:58 sean-k-mooney the cinder team may be ok just using the nova spec for both but we would need them to say one way or another
16:54:22 tkajinam sean-k-mooney, quickly looking at cinder code it seems cinder has no mechanism to validate keys in qos specs
16:54:43 tkajinam the documentation even describes the "delay" which is not actually used IIUC https://docs.openstack.org/api-ref/block-storage/v3/index.html#id768
16:54:59 sean-k-mooney it filters them when puting them in the connection info
16:55:19 sean-k-mooney so it may not filter for backend qos polciies btu it does for frontend ones
16:56:16 tkajinam I mean there is not filtering mechanism in api layer, so what we may need to update is the filtering logic in manager.py which you pointed
16:56:45 sean-k-mooney yes which cinder may or may not consider an api change
16:57:16 sean-k-mooney so they may be happy with jsut the nova spec and say a bug on there side or they may ask for a spec on both sides if they consider it an api change
16:57:29 sean-k-mooney i posted this on the spec more or less
16:57:49 sean-k-mooney although not in those exact words
16:58:35 tkajinam yeah I saw these
16:59:33 sean-k-mooney if you think any addtional context woudl help please reply so the author can condier that. are you overall infaovr or agasitn this feature?
17:05:02 tkajinam sean-k-mooney, I now think that's a good idea. My -1 came from the fact that I overlooked that frontend qos handling
17:05:57 opendevreview Merged openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456
17:20:21 opendevreview Merged openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584
17:20:31 opendevreview Merged openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834
17:20:39 sean-k-mooney gibi: :) ^
17:23:06 opendevreview Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814
17:23:06 opendevreview Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685
17:23:07 opendevreview Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706
17:23:07 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106
17:26:58 gibi sean-k-mooney: \o/
17:27:08 opendevreview Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685
17:27:08 gibi a quick win for Epoxy
17:27:08 opendevreview Takashi Kajinami proposed openstack/nova master: Add hw_mem_encryption_model image property https://review.opendev.org/c/openstack/nova/+/927706
17:27:09 opendevreview Takashi Kajinami proposed openstack/nova master: libvirt: Launch instances with SEV-ES memory encryption https://review.opendev.org/c/openstack/nova/+/926106
20:43:20 opendevreview Artom Lifshitz proposed openstack/nova master: WIP: pwr mgmt: power down free PCPUS when updating compute node https://review.opendev.org/c/openstack/nova/+/932926

Earlier   Later