| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2025-02-18 | |||
| 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 | |
| 20:55:50 | MengyangZhang[m] | i don't think it would cause live-migration fail. We have deployed qos to our private cloud for some time and we don't see increased live-migration failures when existing VMs are adapting the qos | |
| 20:56:20 | sean-k-mooney | it would fail if the destination host did not supprot the qos config | |
| 20:57:10 | sean-k-mooney | i.e. if the souce and destination host had differnt version of libvirt and the qos element was supported on the source but nto the desitnaiton | |
| 20:57:50 | sean-k-mooney | we shoudl be validating that in pre live migration | |
| 20:58:47 | opendevreview | ribaudr proposed openstack/nova master: Augment the LiveMigrateData object https://review.opendev.org/c/openstack/nova/+/942143 | |
| 20:58:48 | opendevreview | ribaudr proposed openstack/nova master: Add live_migratable flag to PCI device specification https://review.opendev.org/c/openstack/nova/+/942144 | |
| 20:58:48 | opendevreview | ribaudr proposed openstack/nova master: Update manager to allow vfio pci device live migration https://review.opendev.org/c/openstack/nova/+/942145 | |
| 20:58:49 | opendevreview | ribaudr proposed openstack/nova master: Update conductor and filters allowing migration with SR-IOV devices https://review.opendev.org/c/openstack/nova/+/942146 | |
| 20:58:49 | opendevreview | ribaudr proposed openstack/nova master: WIP: Update driver to map the targeted address for SR-IOV PCI devices https://review.opendev.org/c/openstack/nova/+/942147 | |
| 20:58:58 | sean-k-mooney | downstream we supprot deploying a single verison of nova across both rhel 8 and rhel 9 host for an extened peoid of time | |
| 21:00:05 | sean-k-mooney | we have at least one custoemr that told use that for regaltory reasoson can only update eithe revery 6-12 months | |
| 21:00:46 | sean-k-mooney | so they would realistically ahve some deployments with a mix of libvirt versions for up to a year | |
| 21:01:31 | MengyangZhang[m] | I think we discussed this at some point, the pre live migration step wouldn't fail plus openstack supported front-side disk qos 13 years ago | |
| 21:02:04 | sean-k-mooney | right for the current set we have it wont fail unless libvir remvoes supprot for a filed in a new version | |
| 21:02:29 | sean-k-mooney | but im making the point that nova does not really expect this to change on live migation | |
| 21:02:44 | MengyangZhang[m] | get it | |