12:01:03 <chandankumar> #startmeeting watcher 12:01:03 <opendevmeet> Meeting started Thu May 22 12:01:03 2025 UTC and is due to finish in 60 minutes. The chair is chandankumar. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01:03 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 12:01:03 <opendevmeet> The meeting name has been set to 'watcher' 12:01:08 <chandankumar> o/ 12:01:19 <chandankumar> who all are around here for watcher meeting? 12:01:29 <dviroel> o/ 12:01:41 <chandankumar> courtesy ping: dviroel amoralej jgilaber_ 12:02:09 <jgilaber> o/ 12:02:14 <morenod> o/ 12:02:31 <rlandy> o/ 12:03:02 <chandankumar> let me start with the first topic 12:03:04 <amoralej> o/ 12:03:20 <chandankumar> #topic Eventlet removal 12:03:36 <sean-k-mooney> o/ 12:03:46 <mtembo> o/ 12:04:07 <chandankumar> dviroel: sent a call for MAAS maintainers 12:04:12 <dviroel> right 12:04:12 <chandankumar> #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/thread/SCKFJ4X6I7OSENXEYNCSJBKV55EP43MC/ 12:04:37 <dviroel> as an action from last meeting, I sent this email to the ML 12:04:46 <dviroel> to call for maintainers for MAAS support 12:04:58 <rlandy> what if no response is received? 12:05:08 <chandankumar> thank you dviroel ! 12:05:19 <dviroel> this is one the things that will be affected by eventlet removal and one of the features that have no testing and docs 12:05:47 <dviroel> i mentioned that we also plan to mark features as experimental, if they lack support/testings/doc 12:06:20 <sean-k-mooney> rlandy: we will mark it expermintal this cycle 12:06:26 <sean-k-mooney> next cycle we will likely deprecate 12:06:41 <sean-k-mooney> and remove in a future reelase 12:06:51 <dviroel> right 12:07:22 <dviroel> once we propose a patch for that, the plan is to send an email again, to announce it 12:07:48 <sean-k-mooney> the ironic integration is in a similar state but i think we have more of a chace of adressing the gaps 12:07:59 <rlandy> ok 12:08:00 <sean-k-mooney> because if noting else we can ask the ironic tema for help 12:08:01 <chandankumar> we can wait for 2 week for response? then propose the patch 12:08:22 <sean-k-mooney> we shoudl mark that as experimental this cycle too but follow up with them when we have time 12:08:41 <sean-k-mooney> no we can propsoe the patch to make it experimental now 12:08:46 <sean-k-mooney> and even merge it 12:08:58 <sean-k-mooney> to remove that label i would liek to see ci in place and docs 12:09:16 <sean-k-mooney> so they can remove the experimental marker when they adress the gaps if someone shows up 12:09:44 <dviroel> right, but we should do the same for all that lack testing and docs too 12:09:53 <sean-k-mooney> yes 12:09:56 <chandankumar> sounds like a plan! 12:09:58 <sean-k-mooney> thats why i raised ironic 12:10:13 <dviroel> that's why it deserves another mail to ML when we do that 12:10:18 <sean-k-mooney> yep 12:10:31 <dviroel> ok 12:10:34 <sean-k-mooney> we shoudl annouch each one we want to mark as experimetnal and or deprecated for visablity 12:10:35 <chandankumar> let me add a action item for marking maas and ironic as a experimental and communicate the same on email 12:10:53 <chandankumar> Anyone one wants to take this action item? 12:11:07 <dviroel> I can take it 12:11:53 <chandankumar> #action dviroel to propose patch for marking MAAS and Ironic support experimental in watcher and communicate the same to the Mailing list 12:12:04 <chandankumar> thank you dviroel ! 12:12:24 <dviroel> np 12:12:28 <chandankumar> there are two open reviews related to eventlet removal 12:12:35 <dviroel> yep, small ones 12:12:39 <chandankumar> 1. https://review.opendev.org/c/openstack/watcher/+/949641: Move eventlet command scripts to a different dir 12:12:40 <dviroel> but a start 12:12:57 <chandankumar> 2. https://review.opendev.org/c/openstack/watcher/+/949658: Remove deprecated executor in message handling servers 12:13:16 <chandankumar> please review it in your free cycles, 12:13:25 <chandankumar> thank you dviroel once again for bringing it up! 12:13:54 <dviroel> I also started working on changes related to the BackgroundSchedulerService and Service class, but I will bring more details in the next meetings 12:14:20 <chandankumar> great! 12:14:43 <chandankumar> dviroel: annything else to add on this topic? 12:14:46 <dviroel> yep, that's all that I 12:14:55 <chandankumar> thank you! 12:14:59 <chandankumar> moving to next topic 12:15:01 <dviroel> tks 12:15:08 <chandankumar> #topic Parameters for volume migration in zone migration strategy 12:15:31 <chandankumar> jgilaber: has proposed this topic and summarized the current state of input parameters for volume migration in the zone migration strategy in this etherpad https://etherpad.opendev.org/p/zone_migration_volume_migration_parameters 12:15:40 <chandankumar> jgilaber: want to introduce it? 12:15:51 <jgilaber> yes thanks chandankumar 12:16:22 <jgilaber> I have a patch for making the dst_pool parameter mandatory in zone migration 12:16:33 <jgilaber> but as amoralej pointed out, the UX is not great 12:16:46 <chandankumar> #link https://etherpad.opendev.org/p/zone_migration_volume_migration_parameters 12:16:47 <jgilaber> there are scenarios where that parameter would not be used at all 12:17:15 <jgilaber> so I wrote in that etherpad the current volume migration scenarios that the strategy supports 12:17:47 <jgilaber> so we can decide on the parameters that we want to keep, and which we want to mark as required 12:18:05 <jgilaber> feel free to add comments to the etherpad 12:18:33 <chandankumar> #link https://review.opendev.org/c/openstack/watcher/+/950149: Handle missing dst_pool parameter in zone_migration 12:18:41 <amoralej> My suggestion would be to rethink which use cases we want to support and which parameter we need to each one based on that 12:19:33 <amoralej> and we may involve some cinder expert to make sure the implementation is correct, as there are some implementation details which are unclear 12:20:26 <amoralej> by use cases i mean: migrate to a new pool, retype in the same pool, or migrate via retype, and also which are the affected volumes, those in the src_pool AND src_type ? 12:21:12 <sean-k-mooney> well thsoe 3 are a oneof choice 12:21:20 <sean-k-mooney> i think its valid to supprot all of the abvoe 12:21:35 <amoralej> i agree, i think those are valid ones 12:22:19 <dviroel> right, but the way that parameters are set to mandatory, don't look correct 12:22:34 <amoralej> but then we need to define interaction between dst_type and dst_pool 12:22:44 <sean-k-mooney> dviroel: well it may be 12:22:46 <dviroel> if you want to retype, you need to set a dst_pool, which is not used by retype 12:22:54 <sean-k-mooney> im nto sure hwo its expsed in the cinder api 12:22:54 <amoralej> not really 12:22:59 <amoralej> only dst_type 12:23:07 <sean-k-mooney> but in nova retyp and codle migrate are implemtned underneate as teh same code 12:23:13 <amoralej> actually, retype does not specify destination pool, only type 12:23:20 <sean-k-mooney> cold migrate is just a resize to the same flavor 12:23:46 <amoralej> but if the dst_type is not assigned to the src_pool it will do also the migration under the hood 12:23:53 <sean-k-mooney> amoralej: right which is likely why this was optional in the first palce 12:24:01 <amoralej> yes, that's my guess too 12:24:25 <sean-k-mooney> so what we need to do is map out each of the possibel api actions we could call 12:24:45 <sean-k-mooney> then map out the vaild import parmater that satify the api consstratits 12:24:54 <sean-k-mooney> and then see who to evolve the scema to match 12:25:27 <sean-k-mooney> for example if you are not retyping then we may requrie teh pools but make them optional or forbdi them if you are 12:25:45 <amoralej> and also, we may want to revise management attached and dettached in the strategy. According to doc we may do migrate or retype for attached unless volumes are multi-attached 12:25:54 <sean-k-mooney> we will have to decied how much to encode in the schema and how much to do in the validate fucntion in the api 12:25:59 <amoralej> ^ this is where it'd be good to get cinder team input 12:26:35 <sean-k-mooney> right multi atatch volume cant be mvoed while they have mroe the one attachment 12:26:40 <sean-k-mooney> so we shoudl filter those out 12:26:41 <dviroel> right, one important thing to check is the multi-attach too 12:27:08 <sean-k-mooney> honestly fixing the cidner part almost feesl like ti should have a spec 12:27:22 <sean-k-mooney> on one hand it might be small and easy 12:27:30 <amoralej> according to the doc, that seems the main limitation to retype/migrate attached volumes. If we filter out those, we probably can unify how we manage attached/dettached 12:27:34 <sean-k-mooney> btu its oen of those things where you reallly need to write it down to reason about it 12:27:50 <amoralej> and document clearly 12:27:54 <sean-k-mooney> shoudl we start a etherpad to try and help with discussion 12:28:05 <jgilaber> yes, I think a spec might be needed here, I doubt it will be a simple change 12:28:11 <amoralej> we can use the one that @jgilaber created 12:28:30 <sean-k-mooney> one other thing to consdier 12:28:35 <sean-k-mooney> if your using ceph 12:28:37 <sean-k-mooney> there are no pools 12:28:39 <amoralej> I'd put a section describing current status and one with the desired behavior 12:28:50 <sean-k-mooney> but you shoudl be able to migrate between ceph clusters 12:29:46 <sean-k-mooney> current and desireed state is defintly somethign we shoudl capture 12:30:00 <amoralej> iiuc migrate call can also migrete from cluster to cluster ? 12:30:17 <jgilaber> there is a cluster option in the api call https://docs.openstack.org/api-ref/block-storage/v3/index.html?expanded=detach-volume-from-server-detail#migrate-a-volume 12:30:26 <dviroel> tbh, this doesn't need to be pools, can be backends, so pool might not be the correct name there too 12:30:26 <jgilaber> I guess that's meant to be used with ceph? 12:31:38 <sean-k-mooney> its not clear 12:32:02 <sean-k-mooney> cinder shoudl have some other admin/user facign docs for this 12:32:08 <amoralej> iiuc in migrate call, when using host, host can be backend or backend#pool 12:32:21 <sean-k-mooney> we can review that but we shoudl also dicuss this mroe with the cinder team 12:32:27 <amoralej> +1 12:32:30 <dviroel> ++ 12:32:37 <chandankumar> +1 12:33:27 <jgilaber> sounds good, short term, what are your thoughts on https://review.opendev.org/c/openstack/watcher/+/950149? should I abandon it, or change the behaviour so that if dst_pool is not passed migration is skipped 12:33:28 <chandankumar> Let me add a action item here to add section describing current state and desired behavior on the etherpad https://etherpad.opendev.org/p/zone_migration_volume_migration_parameters and continue the discussion there 12:33:39 <jgilaber> to avoid the error described in the associated bug 12:34:44 <sean-k-mooney> i think instead of tightenign the schema 12:35:06 <sean-k-mooney> we will end up makeign ti a little looser adn do a more contextural check in python 12:35:11 <amoralej> I don't like making it mandatory tbh 12:35:24 <sean-k-mooney> wll that what i ment by looser 12:35:37 <dviroel> and improve the documentation :) 12:36:11 <sean-k-mooney> we will likely remove the mandaory requirement form other filed as weell and docuemtn the combinations that work adn also add a check outside the scema in the python code to enfoce teh workign combidnations 12:36:40 <sean-k-mooney> i think encoding the logic in jsonschema is going to be overly complex 12:36:57 <amoralej> there will be no way, i'd say 12:37:12 <sean-k-mooney> we have 5+ paralle axis 12:37:17 <jgilaber> I don't see a simple way, no 12:37:36 <amoralej> note that the behavior also depends on how types/pools/backends are configures 12:37:49 <sean-k-mooney> there are 3 diffent storage operations + vm operations and orderign considertaons 12:37:51 <amoralej> so implementing a use case may involve also configure a type in a certain way 12:38:12 <sean-k-mooney> yep 12:38:27 <sean-k-mooney> since we acknowlage this is a gap i think we shoudl move on for now 12:38:34 <jgilaber> +1 12:39:01 <amoralej> short term, something that may fix is to add a check for dst_pool before calling _volume_migrate 12:39:12 <amoralej> if it's not defined, just ignore that volume 12:39:39 <amoralej> we may save some errors, but still the implementation needs to be revised in deep 12:40:03 <amoralej> but yeah, we can move on 12:40:18 <sean-k-mooney> we coudl but that geenally would not be correct api behavior 12:40:46 <sean-k-mooney> if the inputs do not meet the preqistis for the rested orpetaon we shoudl return a 400 12:41:00 <sean-k-mooney> and not attempt to do the operation 12:41:03 <chandankumar> I think we have got some direction on the above review, we can bring this one in the next meeting? 12:41:27 <sean-k-mooney> sure if there is progress on it 12:42:35 <sean-k-mooney> shall we move on to https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L52 12:42:47 <chandankumar> yes let me add one action item 12:43:19 <chandankumar> #action jgilaber to add section describing current state and desired behavior on the etherpad https://etherpad.opendev.org/p/zone_migration_volume_migration_parameters and continue the discussion. 12:43:35 <chandankumar> thank you everyone for the great discussion 12:43:38 <chandankumar> moving to next one 12:43:54 <chandankumar> #topic Reviews 12:44:11 <chandankumar> #link 1. Check logs in some cinder and nova helper tests https://review.opendev.org/c/openstack/watcher/+/949187 12:44:40 <jgilaber> this patch adds tests to reproduce the bug https://bugs.launchpad.net/watcher/+bug/2110149 12:45:07 <jgilaber> some logging calls were misformated, but the unit tests were not logging them 12:45:16 <chandankumar> #link 2. Fix incorrect logging format https://review.opendev.org/c/openstack/watcher/+/822559 12:45:22 <jgilaber> because alembic would reconfigure the logging and disable it 12:45:32 <jgilaber> the second link fixes the logging call 12:45:55 <jgilaber> the patch has been opened for a while, I've taken it over 12:46:18 <sean-k-mooney> i think the only thing i was waiting for on the second patch was for you to update that once you got the logging woring in the previous one 12:46:23 <sean-k-mooney> so ill re review that 12:46:30 <sean-k-mooney> i think directionally the patches are fine 12:46:32 <jgilaber> yes, thanks sean-k-mooney 12:46:42 <chandankumar> #link 3. Add spec for skip actions from action plan executions https://review.opendev.org/c/openstack/watcher-specs/+/949528 12:48:02 <sean-k-mooney> its form this really shade guy by the name of amoralej :) i dont know if we shoudl review 12:48:17 <chandankumar> everybody please take a look at the open reviews and have feedback! 12:48:19 <sean-k-mooney> am that also on my queue 12:48:37 <amoralej> yeah, so there aer a couple of questions open in that spec 12:48:51 <amoralej> i'd like to get the feedback before sending a new version of it 12:49:25 <sean-k-mooney> ack do you want to raise any of them now 12:49:50 <amoralej> one of them is where to allow the transition 12:50:15 <amoralej> i was thinking of allowing actions from PENDING->SKIPPED 12:50:44 <sean-k-mooney> that is what i avocated for on irc when we last spoke about it 12:50:45 <amoralej> but @dviroel made a good point that we should check that not only the action is pending but the parent action plan 12:51:13 <amoralej> it's slightly different 12:51:23 <amoralej> but i think it covers better the intent 12:51:33 <sean-k-mooney> yes that because of how they are stored in teh db 12:52:09 <amoralej> second one is about your proposal of implementin api call ' /v1/action_plans/{plan_id}/actions/{action id or index}' 12:52:31 <sean-k-mooney> without going into the hsitory too much, correct me if im wrong but for some reason tehy deceid to create the actions in the db before the plan is is accpated or rejected 12:52:31 <amoralej> instead of my proposal on patching /v1/actions/{action_id} 12:52:43 <amoralej> exactly 12:52:54 <amoralej> the actions are created as soon as the action plan is created 12:53:03 <sean-k-mooney> right which is a way to do it 12:53:16 <sean-k-mooney> its not how i woudl do it if we wrote it today 12:53:27 <sean-k-mooney> but that is why we need to also check the action plan state 12:53:32 <amoralej> and since then actions are a 1st level api element 12:53:39 <amoralej> not a nested one into action_plans 12:54:08 <sean-k-mooney> tehy are but i am not conficed they shoudl have a writeable api at all 12:54:14 <sean-k-mooney> to me actions are intenal state 12:54:42 <sean-k-mooney> which si why i was expect to modify the actiov via the action plan 12:55:32 <sean-k-mooney> i understand why you wanted to modify it with /v1/actions/{action_id} 12:55:37 <amoralej> wdym by internal state ? 12:56:04 <amoralej> you mean from db store point of view or from api point of view? 12:56:07 <sean-k-mooney> i mean that action are generate by the decsion engine 12:56:24 <sean-k-mooney> use accppat action plans or reject them today 12:56:33 <sean-k-mooney> they do not have granulartiy beyond that 12:56:40 <amoralej> right 12:56:58 <sean-k-mooney> so ot me teh actions are expsoe mroe for debuging or tracablity 12:57:11 <sean-k-mooney> not as a first class thing that user shoudl direcly manipulate 12:57:19 <chandankumar> time check: 3mins left , we have one more topic left 12:57:34 <amoralej> ok, i think i get your point 12:57:34 <sean-k-mooney> now we coudl open them up to the user 12:57:51 <sean-k-mooney> bu tsicne they cant be sued on tehre own it feels a bit wer to do that 12:58:34 <amoralej> i see what do you mean now 12:59:11 <sean-k-mooney> we can do what you suggest btu to me that is a larger chnage then i intially tought 12:59:12 <amoralej> but in practical terms, i think it will be harder to implement your way 12:59:17 <amoralej> with small win, imo 12:59:46 <sean-k-mooney> so the other thing im reflecting on is im not sure we shoudl be supproting patch on any of the apis 12:59:55 <amoralej> implementing a call to /v1/action_plans/{plan_id}/actions/{action id or index} would require to also implement new api attribute actions under the action_plan 13:00:15 <sean-k-mooney> yes 13:00:25 <sean-k-mooney> and we will need a new one for actions also 13:00:36 <sean-k-mooney> for the patch method if we decied to supprot htat 13:00:43 <amoralej> well, we will need to add the patch method 13:00:45 <amoralej> right 13:01:01 <sean-k-mooney> so im more inclide to modeel this after nova instance actions insead 13:01:11 <amoralej> but wouldn't be that much easier that adding showing the actions under action_plan + patch/post 13:01:12 <amoralej> ? 13:01:18 <sean-k-mooney> btu that a longer dicssion then our -1 mins allow 13:01:24 <amoralej> yeah 13:01:39 <sean-k-mooney> amoralej: eiaser yes 13:01:41 <chandankumar> sean-k-mooney: amoralej I think we can take up this discussion on the spec itself? 13:01:44 <sean-k-mooney> correct im not sure 13:01:55 <sean-k-mooney> yep 13:02:12 <chandankumar> or we can do a spec review meeting in future to review the spec. 13:02:34 <amoralej> +1 13:02:42 <chandankumar> Do we want to skip the bug triage for today? 13:02:48 <sean-k-mooney> we can carry on the converstaion in gerrit and we can chat on irc outside the meeting as weel 13:03:00 <sean-k-mooney> i think so 13:03:12 <chandankumar> I will paste the bug links here, feel free to take a look 13:03:15 <amoralej> we are 3 minutes overtime, so i guess so 13:03:26 <chandankumar> #link https://bugs.launchpad.net/watcher/+bug/2110895 - Drop post/patch/delete undocumented rest api call from watcher action 13:03:37 <chandankumar> #link https://bugs.launchpad.net/watcher/+bug/2110897 - Add more docs around openstack optimize audit command in doc 13:03:51 <chandankumar> #link https://bugs.launchpad.net/watcher/+bug/2107467 (workload_stabilization strategy does not show standard_deviation if it's below the audit thre 13:04:01 <chandankumar> #link https://bugs.launchpad.net/watcher/+bug/2110991 [doc] Plugin docs still refers to Voluptuous schemas 13:04:09 <chandankumar> going over last topic 13:04:19 <chandankumar> #topic volunteer to chair next meeting 13:04:24 <chandankumar> anyone up for that? 13:04:46 <rlandy> I'll do it 13:04:59 <chandankumar> #action rlandy to chair for next meeting 13:05:03 <chandankumar> rlandy: thank you! 13:05:08 <chandankumar> time to wrap up! 13:05:08 <dviroel> ++ 13:05:11 <chandankumar> #endmeeting