| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-18 | |||
| 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 | |
| 20:31:34 | opendevreview | Merged openstack/nova stable/2024.1: ironic: Fix ConflictException when deleting server https://review.opendev.org/c/openstack/nova/+/940846 | |
| 20:32:27 | sean-k-mooney | MengyangZhang[m]: if it allow the volume type ot be updated after its in use does it also propagte those changes to instance when a new attachment is created | |
| 20:32:42 | sean-k-mooney | or does it update the conetnt for exsiting attachments | |
| 20:33:33 | MengyangZhang[m] | to new attachment, existing volumes must be reattached to have the update applied | |
| 20:34:20 | sean-k-mooney | ack so that not great as i treally should only update it if you do a volume retype | |
| 20:34:41 | sean-k-mooney | but its less bad then otherwise | |
| 20:37:36 | sean-k-mooney | what we really need is an per volume api call to trigger the atachment update. the worst case sensiario is you create a new qos policy, you apply it to a volume time and cinder tirggers all volumesof that type ot be udpated | |
| 20:38:17 | sean-k-mooney | by that i mean | |
| 20:38:50 | sean-k-mooney | it would be a problem if cidner tirgger nova to call libvirt to update all fontend qos on all affected volumes | |
| 20:41:29 | sean-k-mooney | its tricky but how nova would expect cidner to work is that when a voluem is created iwth a given voluem type. the defintion fo that voluem type should be snapshot and saved per voloume and used for the lifetime of the volume | |
| 20:42:00 | sean-k-mooney | meaning the only way to update a voluem to get the new qos would be via a voluem retype ot the same or a diffent volume type | |
| 20:42:29 | sean-k-mooney | that is how we handel flavors and iamges | |
| 20:43:33 | sean-k-mooney | it sounds like cinder is not doing this | |
| 20:48:44 | MengyangZhang[m] | No, not for live migration/resize coz qos limits are saved in cinder.quality_of_service_specs db table and it is only assoicated with volume type. I don't see qos values are saved on a per volume basis. Thus, when volume attachment event happens, they just fetch qos limits associated with the volume type and popolate to the connection_info field, which then passed back to nova to generate xml | |
| 20:50:52 | MengyangZhang[m] | The reboot however works a bit different. I believe it is reading the connection_info from nova.block_device_mapping db, which saves a snapshot of volume qos and use it for the lifetime of the instance. | |
| 20:51:09 | sean-k-mooney | right so that probelmatic becasue it shoudl not change on a live migration | |
| 20:51:57 | sean-k-mooney | the reboot behavior in nova is how it shoudl work | |
| 20:52:36 | sean-k-mooney | the qos policy applied to an instnace volume shoudl not change as a sideffect changing the host | |
| 20:53:09 | MengyangZhang[m] | understood, then what we should do? discuss this in next cinder-nova meeting? | |
| 20:53:25 | sean-k-mooney | i think so yes | |
| 20:53:45 | sean-k-mooney | i do not know if modifying the QOS could cause the live migration to fail for example | |
| 20:53:57 | sean-k-mooney | or cause issues with reverting a cold migrate or resize | |