Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2025-02-18
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
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

Earlier   Later