Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-10-29
16:13:35 bauzas ack
16:13:41 sean-k-mooney the packaging of that is a bit weired and may have changed
16:13:49 bauzas I guess we're cool then
16:13:58 sean-k-mooney more or less
16:14:02 opendevreview Merged openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590
16:14:10 sean-k-mooney i think we can just review this as normal
16:14:17 sean-k-mooney and check in each week until merged
16:15:05 bauzas ok, moving on then
16:15:57 bauzas #topic Release Planning
16:16:03 bauzas #link https://releases.openstack.org/epoxy/schedule.html
16:16:09 bauzas #action bauzas to add Epoxy nova deadlines in the schedule
16:16:41 bauzas if you were not present at the PTG, you need to know that we'll have a spec soft freeze by mid-Dec
16:16:54 bauzas plan in advance to write your spec accordingly
16:17:10 bauzas the earlier the better as always
16:17:24 bauzas #topic Review priorities
16:17:30 bauzas #link https://etherpad.opendev.org/p/nova-2025.1-status
16:17:55 bauzas I moved some stuff, but I need to do a scan check of all the items in there
16:18:19 bauzas #topic PTG summary
16:18:27 bauzas for those who were not able to attend :
16:18:36 bauzas #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/HZZPADKTWNMBGRSOEMSPLN432DXZYYTL/
16:18:52 bauzas feel free to raise questions or remarks in that thread
16:19:05 bauzas #topic Stable Branches
16:19:18 bauzas hah, elodilles_pto is on PTO as the nick says
16:19:40 bauzas let's move on then to the next topic unless someone wants to raise something about stable branches
16:19:45 zigo FYI (about this link): We'd love to have "vTPM live migration" implemented... :P
16:20:01 bauzas zigo: make a wish
16:20:31 sean-k-mooney many woudl and there is at least some hope that it will be doen in epoxy
16:20:57 sean-k-mooney its non trivial however without wekening security
16:20:58 bauzas there is already some code there so the wish wouldn't be too hard to do
16:21:49 sean-k-mooney yes and no the current code is not accpabel as is as it wont work in the general case without custom policy
16:21:52 bauzas zigo: if you really like the case, please review the spec then once it's uploaded
16:22:05 sean-k-mooney but that is why we are goign to have a spec and try and delvier a better generic solution
16:22:40 bauzas zigo: as sean-k-mooney is explaining, we discussed about user bond of trust with admins
16:22:57 bauzas so I'd like your op voice to be shared on that spec
16:23:49 bauzas anyway, let's not derail the meeting into a technical discussion about a specific feature
16:24:20 bauzas moving on (and I think we can skip the stable branches topic for today)
16:24:23 bauzas #topic vmwareapi 3rd-party CI efforts Highlights
16:24:33 bauzas fwiesel: want to share something ?
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 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-29-16.00.log.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 Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-10-29-16.00.html
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 bauzas #endmeeting
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

Earlier   Later