| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-18 | |||
| 17:01:15 | opendevmeet | Meeting ended Tue Feb 18 17:01:15 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:01:15 | bauzas | #endmeeting | |
| 17:01:42 | sean-k-mooney | MengyangZhang[m]: i think we woudl need a nova cinder corss project seesion on this topic for the cinder case | |
| 17:02:32 | cardoe | https://review.opendev.org/c/openstack/nova/+/942019 is just a simple message fix that I was gonna see if I could also backport to 2024.2 (and technically affects back to 2024.1) Not sure if there's some test or release note you guys would like me to add. | |
| 17:02:51 | MengyangZhang[m] | Yes, make sense. So we discuss it on Thur? | |
| 17:02:54 | r-taketn | thanks | |
| 17:09:03 | MengyangZhang[m] | ||
| 17:09:23 | sean-k-mooney | MengyangZhang[m]: likely how we would need to do this si to add a new external event that cidner could call back when qos is modifed on a volume | |
| 17:10:28 | sean-k-mooney | we would also need to call them back to etier complet the update or fail it | |
| 17:12:21 | MengyangZhang[m] | make sense. I can look into this a bit more closely, but since this may be a large project, just want to make sure the community is interested in the idea so we can start working on it in my company | |
| 17:12:25 | sean-k-mooney | MengyangZhang[m]: have you written a cidner spec for this yet? i suspect we will need one for cinder and another for nova as it would need api change on both sides | |
| 17:13:27 | MengyangZhang[m] | not yet, yes spec makes complete sense. will work on it next | |
| 17:13:47 | sean-k-mooney | MengyangZhang[m]: this is similar compelxtity to https://specs.openstack.org/openstack/nova-specs/specs/2024.2/approved/assisted-volume-extend.html | |
| 17:14:10 | sean-k-mooney | https://review.opendev.org/c/openstack/cinder-specs/+/866718 | |
| 17:15:17 | sean-k-mooney | MengyangZhang[m]: while POC are useful in general its expected to agree the design in a spec before working on the code | |
| 17:16:58 | sean-k-mooney | if we focus on the cidner usecase what your really tryign to adress is the gap for frontend qos when you do "openstack volume qos associate QOS_ID VOLUME_TYPE_ID" | |
| 17:19:00 | sean-k-mooney | ... why are they using a get request to make a change... | |
| 17:19:03 | sean-k-mooney | https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=detach-volume-from-server-detail#associate-qos-specification-with-a-volume-type | |
| 17:19:09 | sean-k-mooney | anyway that return a 202 | |
| 17:19:09 | MengyangZhang[m] | For cinder, there are two requests, one is per project qos not the per volume type qos. Secondly, once the qos policy is changed, we want to let the existing vm automatically adopt the new limits instead of requireing a live-migration to adopt it | |
| 17:19:54 | sean-k-mooney | today it shoudl eb returing a 409 conflict if the volume is attached to and isntance and the qos policy has frontent qos | |
| 17:20:30 | sean-k-mooney | MengyangZhang[m]: live migration shoudl not cause it to update today | |
| 17:20:52 | sean-k-mooney | if it does that proably a bug | |
| 17:21:34 | sean-k-mooney | i stongly suspect that cidner api is not propelry reject assocateing a qos policy with a volume that is in-use when the policy has front end qos | |
| 17:21:43 | sean-k-mooney | it it allows that today that is wrong | |
| 17:25:24 | MengyangZhang[m] | Let me double check it | |
| 17:26:16 | sean-k-mooney | it woudl be a prety seriours api bug on there side | |
| 17:26:39 | sean-k-mooney | because they would allow the requested state and the actual state to get out of sync | |
| 17:27:00 | sean-k-mooney | which could lead to late failure the next tiem a user hard reboots an instnace | |
| 17:30:03 | MengyangZhang[m] | I will perform some testing locally and get back to you on this | |
| 17:30:49 | sean-k-mooney | if you can apply a qos policy to a volume that is in use and that policy has a frontend qos rule then its a cidner api bug form my perspecitve | |
| 17:31:21 | sean-k-mooney | its not ok to make a change i nthe cinder api and only have it take effect potentialy month later the next time the vm is moved or the xml is otherwise regenerated | |
| 17:32:46 | sean-k-mooney | the current api is written in terms of the volume type | |
| 17:32:56 | sean-k-mooney | nto in terms fo a volume | |
| 17:33:58 | sean-k-mooney | cinder shoudl not apply the qos update to existing instance or the updated type until a retyp or simialr api call is done | |
| 17:41:36 | opendevreview | Sylvain Bauza proposed openstack/nova master: Add a new ImagePropertiesWeigher https://review.opendev.org/c/openstack/nova/+/940642 | |
| 17:41:37 | opendevreview | Sylvain Bauza proposed openstack/nova master: per-property ImageMetaPropsWeigher https://review.opendev.org/c/openstack/nova/+/941601 | |
| 17:48:24 | MengyangZhang[m] | <sean-k-mooney> "its not ok to make a change i..." <- unfortunately, that's the case now. If a qos policy is created and associated with a volume type, then all in-use volumes of that type will get qos limits when the xml is regenerated, like during live migration or resize. | |
| 17:49:04 | MengyangZhang[m] | <sean-k-mooney> "cinder shoudl not apply the..." <- what do you mean by retype? | |
| 17:54:35 | gmann | bauzas: sean-k-mooney: RE on RBAC spec, I read the meeting log. I am ok with decision and understand if no core has bandwidth to review it. I will see what best can be done in next cycle. | |
| 17:55:38 | sean-k-mooney | gmann: if you have the patches in a mergabel state with testing i dotn see why we woudl really wait once we are passed teh RC peroid | |
| 17:55:55 | gmann | mikal: I am in PST TZ, I will check tempest change after TC meeting (~ 1hr from now) | |
| 17:55:56 | sean-k-mooney | we can approved the spec for next cycle | |
| 17:56:29 | gmann | ack | |
| 17:56:41 | sean-k-mooney | i dont kwno how practical it is but it woudl be ncie to compelte it before the PTG for example | |
| 17:58:09 | sean-k-mooney | certinly its a good candiate to complete before m1 | |
| 17:58:26 | sean-k-mooney | i just dont know how much tiem we will all have with release activies ectra | |
| 18:01:01 | gmann | yeah, let me finish the code change first before re-proposing the spec. manger role is all good but i need to finish the service role thjings | |
| 18:02:25 | sean-k-mooney | does one need the other. both are covered by the same spec but we do not need to complet eboth to merge it right | |
| 18:02:50 | sean-k-mooney | if the manager role is working that can be merged first and then teh service user role change can come after? | |
| 18:04:55 | gmann | both are separate, I was little lazy to put both in one effort. this is manager role change and its parent add manager role context in unit tests so that we can see how manager role addition looks like https://review.opendev.org/c/openstack/nova/+/941347/2 | |
| 18:05:26 | sean-k-mooney | well i dont really mind them both being in the same spec | |
| 18:05:32 | gmann | and manager role is more I am interested to do as that is user usable things and service-role is just (but still important ) to improve the internal communication | |
| 18:05:58 | sean-k-mooney | right | |
| 18:06:28 | sean-k-mooney | i woudl proably do them in that order too | |
| 18:07:37 | gmann | sean-k-mooney: what you suggest now? do you want me to separate spec for manager role if that can be done in this cycle? you can see the code change for manager role to answer it. | |
| 18:08:02 | gmann | https://review.opendev.org/c/openstack/nova/+/941056/2 and https://review.opendev.org/c/openstack/nova/+/941347/2 | |
| 18:09:03 | sean-k-mooney | if we wanted to try and get some provess this cycle that might be achivele givent its only 2 relitivly small pathces | |
| 18:09:17 | sean-k-mooney | my concern woudl still be with testing | |
| 18:09:24 | sean-k-mooney | have you any tempest coverage for that | |
| 18:09:47 | sean-k-mooney | oh https://review.opendev.org/c/openstack/tempest/+/941594 | |
| 18:09:57 | sean-k-mooney | and thast merged already | |
| 18:11:06 | sean-k-mooney | although that not reall testing it | |
| 18:24:19 | gmann | policy changes are from ADMIN -> manager-or-ADMIN and tempest tests testing those with admin so no impact but there are two policy changes form member-or-admin to manager-or-admin which is impact but tempest test tests them admin only. | |
| 18:24:58 | sean-k-mooney | im almost finished quicckly reviewign the manager patches but there are issues in the second one | |
| 18:24:59 | gmann | sean-k-mooney: tempest testing you mean to test those policy with manager role instead of admin? manager role access is asserted in unit tests | |
| 18:25:48 | sean-k-mooney | correct to asssert that with the new default policy a client with the manger role could cold migrate for example | |
| 18:26:14 | gmann | then we loose coverage of doing it with manager role | |
| 18:26:31 | gmann | unless we run same tests with two role admin and manager | |
| 18:26:47 | sean-k-mooney | yes i was suggesting doing it with both admin and manager | |
| 18:26:51 | gmann | * then we loose coverage of doing it with ADMIN role | |
| 18:27:39 | sean-k-mooney | althoguht that is really jsut testign the implied roles feature irght | |
| 18:27:50 | sean-k-mooney | admin would imply manager | |
| 18:28:02 | gmann | that might be add more time in tempest jobs if we test APIs with all possible policy defaults. bcz it is same for member-or-reader | |
| 18:28:19 | sean-k-mooney | unlike service i dont see a reason for it to siad the default heriachy | |
| 18:28:26 | gmann | sean-k-mooney: yeah, that I was about to write. I think testing with manager is least permissible default role testing we need | |
| 18:28:42 | gmann | and admin anyways should have access on anything manager can do | |
| 18:28:56 | gmann | sean-k-mooney: let me modify the tempest test and see | |
| 18:30:46 | sean-k-mooney | i guess there is one differnce | |
| 18:31:17 | sean-k-mooney | we can jsut use project manager in the roles becuase when you have the admin role we do not need to compre the project id | |
| 18:32:08 | sean-k-mooney | so we do actully need to have PROJECT_MANAGER_OR_ADMIN for api that are valid to call form both | |
| 18:32:38 | sean-k-mooney | although on the tempest side i dotn think that changes thigns | |
| 18:34:00 | gmann | yeah | |
| 18:35:22 | priteau | Hello. Could a Nova core approve this backport please? https://review.opendev.org/c/openstack/nova/+/940846 I have just tested it and it resolves our baremetal node deletion issues. | |
| 18:36:35 | sean-k-mooney | ah the 2024.1 backport | |
| 18:36:37 | sean-k-mooney | sure | |
| 18:36:39 | gmann | sean-k-mooney: anyways let me see if I can finish the testing otherwise I am ok not to be in hurry in this cycle. The main reason is that I am struggling with my bandwidth for upstream activities at least for next few months also. | |
| 18:37:24 | sean-k-mooney | gmann: i finsihed reviewing the manger changes and i dont think you updated it with the dicussion form the spec | |
| 18:37:46 | sean-k-mooney | i was also expecting you to modify instnace lock btu maybe that was nto covered | |
| 18:37:55 | sean-k-mooney | i didnt look at the spec in a while | |
| 18:38:56 | gmann | In spec, we left the lock and other server action. I explicitly mentioned those as not-changing-those | |
| 18:40:20 | sean-k-mooney | i was expectign you to allow the manager ot unlock an admin locked insntace | |
| 18:40:31 | sean-k-mooney | but not restrict lock to manager | |
| 18:40:35 | sean-k-mooney | but that is fine | |
| 18:41:12 | sean-k-mooney | priteau: approved :) | |
| 19:16:04 | dansmith | bauzas: still around? | |
| 19:31:16 | opendevreview | Michael Still proposed openstack/nova master: libvirt: allow direct SPICE connections to qemu https://review.opendev.org/c/openstack/nova/+/924844 | |
| 19:42:19 | priteau | sean-k-mooney: thanks! | |
| 20:29:36 | MengyangZhang[m] | <sean-k-mooney> "cinder shoudl not apply the..." <- unfortunately this is the case now. How should I proceed then? | |
| 20:31:30 | sean-k-mooney | it depend | |