12:01:04 <dviroel> #startmeeting watcher
12:01:04 <opendevmeet> Meeting started Thu May 15 12:01:04 2025 UTC and is due to finish in 60 minutes.  The chair is dviroel. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01:04 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:01:04 <opendevmeet> The meeting name has been set to 'watcher'
12:01:28 <dviroel> hi all, who's around?
12:01:40 <jgilaber> o/
12:02:08 <chandankumar> o/
12:02:20 <rlandy> o/
12:02:22 <mtembo> o/
12:02:29 <dviroel> courtesy ping: amoralej
12:02:49 <dviroel> i proposed the courtesy ping list in one of the past meetings
12:03:31 <dviroel> the idea is that, if you put your nick there, you are going to receive a ping at the beggining of the meetings ... unless you are already here, i can skip your nick :)
12:03:55 <dviroel> let's start with today's meeting agenda
12:04:09 <dviroel> #link https://etherpad.opendev.org/p/openstack-watcher-irc-meeting#L36 (Meeting agenda)
12:04:19 <dviroel> feel free to add your own topics to the agenda
12:04:42 <dviroel> there is a topic to place your changes that requires attention from reviewers
12:05:07 <dviroel> as also a bug triage topic, if you want to bring any for discussion
12:05:34 <dviroel> starting with the first one
12:05:44 <dviroel> #topic Eventlet Removal
12:06:09 <dviroel> the plan here is to circle this topic every week
12:06:30 <dviroel> to follow up progress for this goal, get some feedback and call for actions
12:07:02 <dviroel> this is the etherpad that we capture progress and discussions around eventlet removal in watcher
12:07:05 <dviroel> #link https://etherpad.opendev.org/p/watcher-eventlet-removal
12:07:49 <dviroel> at the top, there are some changes that were already proposed, but this is just a start
12:08:00 <dviroel> to prepare for next changes
12:08:10 <dviroel> so i am calling for review of these ones
12:08:20 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/949641 (Move eventlet command scripts to a different dir)
12:08:25 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/949658 (Remove deprecated executor in message handling servers)
12:09:02 <dviroel> we can capture discussions in the etherpad or in the code review
12:09:23 <dviroel> or even here in the irc channel
12:09:38 <dviroel> ok, next thing in this topic is
12:10:14 <dviroel> maas (metal as a service) support
12:10:40 <dviroel> i want to highlight that the maas integration which will be affect by the eventlet removal
12:11:05 <dviroel> the asyncio compatible call in the code will require change and testing
12:11:10 <dviroel> see
12:11:11 <dviroel> #link https://opendev.org/openstack/watcher/src/commit/1b12e808827ac64d3972443927fc2d070c227023/watcher/common/utils.py#L173
12:11:47 <dviroel> but the point is that we don't have the knowledge and cycle to work on this feature
12:11:54 <jgilaber> do we have any testing for it currently=
12:11:56 <jgilaber> ?
12:11:58 <dviroel> not even how to test it
12:12:05 <dviroel> jgilaber: no
12:12:26 <dviroel> we miss a CI testing and more documentation too
12:12:44 <dviroel> while chatting with sean-k-mooney these days
12:13:05 <jgilaber> ack, should we like we did for the monasca and grafana datasources?
12:13:24 <jgilaber> mark as deprecated and see if someone is interested in it?
12:13:26 <dviroel> we discussed about marking it as an experimental feature during this cycle
12:13:30 <dviroel> and call for maintainers
12:13:46 <jgilaber> that sounds good to me
12:13:50 <sean-k-mooney> o/
12:13:51 <dviroel> in case we don't find any, we could mark it as deprecated in the next cycle
12:14:00 <dviroel> and for removal in the following one
12:14:14 * dviroel sean-k-mooney o/  -  talking about maas support
12:14:24 <sean-k-mooney> ack
12:14:52 <sean-k-mooney> this kind of ties back into one fo the ptg topics
12:15:04 <sean-k-mooney> to add a supprot level matrics to our docs
12:15:33 <sean-k-mooney> i think the maas supprot is perhaps the first but not nessisarly the last one to be consierd experimental
12:15:44 <dviroel> yes, we miss that in our docs for sure
12:16:14 <sean-k-mooney> we also do not have testing of the ironic integration but we may be able to fill that gap more easilly since there are ironci devstack jobs so we can likely borrow some config form them
12:16:37 <sean-k-mooney> for nwo it would also consider markign ironic as expermintal applying the same logic but that can be done sepreatly
12:17:10 <sean-k-mooney> i dont belive there is a maas devstack plugin or a refence job we can pull from to close the maas gap ourselves
12:17:23 <dviroel> agree
12:18:20 <dviroel> so the proposal is to call for maintainers of the maas in the ML
12:18:30 <dviroel> since it will be affected by the eventlet removal
12:18:50 <dviroel> and we lack testing or knowledge on this to maintain it
12:18:55 <sean-k-mooney> well that adn the fact is has no docs or integration testing
12:19:12 <sean-k-mooney> so we dont really knwo how to deploy it even if there was a bug with it to fix it
12:19:20 <dviroel> exactly
12:19:28 <sean-k-mooney> i am wawre that there was some ubuntu charm installer supprot
12:19:36 <sean-k-mooney> however they have moved on to sunbeam
12:19:43 <sean-k-mooney> and i dont belive its supproted there
12:20:01 <sean-k-mooney> so im not sure if any activly devloped installer currently suprpot deploying in this mode
12:20:23 <sean-k-mooney> anyway i agree with your propsoal
12:20:56 <dviroel> #action dviroel to send an email to mailing list to call for maintainers of the maas support
12:22:20 <dviroel> ok, anything else in this topic?
12:23:24 <dviroel> #topic call for reviews
12:23:37 <dviroel> 1. Set keystone_client default interface to internal
12:23:47 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/948322
12:23:56 <sean-k-mooney> i think we ended up defaulting to public?
12:24:12 <jgilaber> yes, I changed that in the last patchset
12:24:27 <sean-k-mooney> ya so long term we shoudl replace our current config option
12:24:38 <sean-k-mooney> with valid_interface form oslo
12:24:48 <sean-k-mooney> valid_interfaces is a preferncally orderd list
12:25:04 <sean-k-mooney> so we can eventually default to internal,public
12:25:21 <sean-k-mooney> and it will use the internal endpoint if its aviabel but fall back to public which should always exist
12:25:39 <sean-k-mooney> i think that woudl be a ncie wishlist feature for all the clients
12:25:50 <dviroel> yeah, that's a got rfe
12:25:52 <sean-k-mooney> but we may want to consider that as part of moving to the openstack sdk
12:25:58 <dviroel> s/got/good
12:26:26 <sean-k-mooney> i have approved https://review.opendev.org/c/openstack/watcher/+/948322
12:26:38 <dviroel> thanks sean-k-mooney
12:26:43 <dviroel> moving to the next one
12:26:49 <jgilaber> thanks!
12:26:55 <dviroel> 2. Migrate value column of efficacy indicator on load
12:27:04 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/949640
12:27:16 <jgilaber> This is a follow up from https://review.opendev.org/c/openstack/watcher/+/945199
12:27:28 <dviroel> it is a new one (at least for me)
12:27:40 <dviroel> ack
12:27:42 <jgilaber> in that patch we modified the db schema for efficacy indicators
12:28:08 <jgilaber> and we could read the old column as fallback, but we're not updating the db back to use the old column
12:28:14 <jgilaber> this patch implements that
12:28:34 <sean-k-mooney> yes its a followup ot "heal the db over time" it will eventually allow us to drop the old column
12:29:07 <dviroel> ack, going to take a look afterwards, tks jgilaber
12:29:12 <jgilaber> thanks!
12:29:24 <sean-k-mooney> the alternitive would have been a "blocker" onlien migration to be ran prior to upgradign to the release where the old colmn is remvoed
12:29:37 <sean-k-mooney> we likely wont do the removal until 2026.2 or later
12:29:57 <sean-k-mooney> but the sooner we have the migration code the lower the impact
12:30:02 <sean-k-mooney> i have added ot my review list
12:30:16 <dviroel> next, also from jgilaber
12:30:20 <dviroel> 3. Add test for missing destination in zone migration
12:30:29 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/948865
12:30:51 <dviroel> and 4. Handle missing dst parameters in zone_migration
12:30:54 <dviroel> #link https://review.opendev.org/c/openstack/watcher/+/948866
12:30:59 <dviroel> which are related
12:31:33 <sean-k-mooney> right the first one is the repoducer for https://bugs.launchpad.net/watcher/+bug/2108988 it should have Related-Bug: #2108988
12:31:35 <jgilaber> they are a reproducer and fix for https://bugs.launchpad.net/watcher/+bug/2108988, which we discussed last week I think
12:31:36 <sean-k-mooney> in the commit
12:32:25 <jgilaber> yes, in short, the zone_migration strategy is not handling correctly the cases where the destination is not set by the user
12:32:26 <sean-k-mooney> quick glance both look ok
12:32:37 <dviroel> is it a fix that we plan to backport?
12:32:40 <jgilaber> for both instance and storage migration
12:32:56 <jgilaber> I think this one we could backport
12:33:01 <sean-k-mooney> that a good question
12:33:16 <sean-k-mooney> i think it can be backported potentially
12:33:17 <jgilaber> it's only changing the strategy code
12:33:32 <jgilaber> the parameters are the same
12:34:04 <dviroel> i miss a release note for that, but I will review the patch afterwards
12:34:21 <jgilaber> yes, I just realized that, I'll add it after the meeting
12:34:21 <sean-k-mooney> we shoudl have  a release note in the second patch yes
12:34:38 <sean-k-mooney> looking at the input parmater schema
12:34:52 <sean-k-mooney> the dst_node was intended to be optional
12:34:59 <sean-k-mooney> so this is really just fixing that
12:35:12 <sean-k-mooney> and reconsiling the implemetion with the schema
12:36:09 <sean-k-mooney> although
12:36:23 <sean-k-mooney> dest_pool is also ment to be optional but we are treating that as an error
12:36:57 <sean-k-mooney> we can continue this in the gerrit review but if we are going to require the dst_pool we may want to udpate the schema but we might decied to do that in a differnt
12:36:59 <sean-k-mooney> patch
12:37:33 <dviroel> sean-k-mooney: ack, thanks for raising this, we can continue in the review yes
12:37:43 <sean-k-mooney> im inclined to split the fix into two patches one for the compute part and one for  the storage part
12:37:44 <jgilaber> that one is more complicated and I'm not sure that what I implemented is the best approach, but yes, let's discuss it in the patch
12:38:06 <jgilaber> that would be fair
12:38:11 <dviroel> tks jgilaber for working on these
12:38:28 <jgilaber> np! thanks for the discussion
12:38:45 <dviroel> we have 2 more in the list
12:39:04 <dviroel> 5. add tests for host_maintenance strategy with backup node
12:39:07 <dviroel> #link https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/947944
12:39:32 <dviroel> from chandankumar
12:39:57 <dviroel> ok, adding tests,  i will review afterwards..
12:40:09 <chandankumar> this cr adds tempest tests for host maintenance strategy with backnode. we have recently fixed the host maintenance strategy with backup node, it will extend the coverage.
12:40:46 <dviroel> chandankumar: ack, tks
12:40:48 <dviroel> and
12:40:51 <dviroel> 6. use get_host_for_server to get server host
12:40:53 <dviroel> #link https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/949557
12:41:09 <chandankumar> we had a nice discussion on this cr related to getting host name of compute server. the second cr is a follow of that
12:41:50 <dviroel> right, i remember that
12:41:51 <sean-k-mooney> i think it would be ok to proceed with this
12:42:09 <chandankumar> tempest scenario manager provides get_host_for_server method https://github.com/openstack/tempest/blob/master/tempest/scenario/manager.py#L1347 that I will using it in all scenario
12:42:19 <sean-k-mooney> although i see althoguh we apprently need a promoation for the operator job to pass
12:42:37 <sean-k-mooney> based on https://review.opendev.org/c/openstack/watcher-tempest-plugin/+/947944/comments/cf2d8a7a_45ef8a99
12:42:51 <chandankumar> yes we need a promotion for operator job to pass which is blocked on different reason
12:43:25 <sean-k-mooney> so we may want ot alter how this works by default
12:43:42 <sean-k-mooney> we might want the master job to alwasy use master watcher form opendev
12:44:03 <sean-k-mooney> and have the content provider build those contianer and avoid usign the rdo content
12:44:19 <sean-k-mooney> we can discuss that seperatly
12:44:28 <sean-k-mooney> but that would eb closer to how we test with devstack
12:44:45 <chandankumar> sean-k-mooney: that's a nice suggestion to build watcher from source always. I will add it to my backlog.
12:45:18 <dviroel> great, tks chandankumar  - lets continue this discussion afterwards then
12:45:43 <dviroel> thats all for review in the etherpad for today
12:45:52 <opendevreview> Merged openstack/watcher master: Set keystone_client default interface to public  https://review.opendev.org/c/openstack/watcher/+/948322
12:45:54 <dviroel> #topic bug triage
12:46:08 <dviroel> https://bugs.launchpad.net/watcher/+bug/2108994 (apscheduler retrieving decimal.Decimal via sqlalchemy)
12:46:41 <dviroel> #undo
12:46:41 <opendevmeet> Removing item from minutes: #link https://bugs.launchpad.net/watcher/+bug/2108994
12:46:46 <dviroel> #link https://bugs.launchpad.net/watcher/+bug/2108994 (apscheduler retrieving decimal.Decimal via sqlalchemy)
12:47:24 <dviroel> this is a new one
12:49:39 <sean-k-mooney> hum
12:50:22 <sean-k-mooney> this feels like we are again not usign the correct types
12:51:23 <sean-k-mooney> so
12:51:33 <sean-k-mooney> its reported again 2023.2
12:51:41 <sean-k-mooney> against
12:51:50 <sean-k-mooney> which is eol
12:52:08 <sean-k-mooney> and its missing some of the squlight backports i thik
12:52:23 <dviroel> hum good point
12:52:49 <sean-k-mooney> if this can be replicated on master we coudl fix it but if not then i think we would close eol
12:53:04 <dviroel> right
12:53:21 <sean-k-mooney> i think this is yet another place where we shoudl not be using decimal
12:53:47 <sean-k-mooney> i wonder if the colume is declard as numeric, int float or a timestampe of some type
12:54:29 <jgilaber> I looked in a deployment I have active and the next_run_time column is created as a double
12:54:30 <dviroel> jgilaber: hey, if you have some time, can you take a quick look in this bug?
12:54:32 <sean-k-mooney> if we are usign decimal anywhere in watcher that is also proably a code smell for a potential bug
12:55:07 <jgilaber> I assume that is where the problem is coming from the next_run_time column in the apscheduler_jobs table
12:55:48 <jgilaber> I can try to look into it a bit later today
12:56:08 <dviroel> ack, tks jgilaber - please add your findings to the bug
12:57:00 <dviroel> i will add a comment on the bug to reference this meeting logs
12:57:07 <dviroel> lets cover one more
12:57:19 <dviroel> #link https://bugs.launchpad.net/watcher/+bug/2110895 - Drop post/patch/delete undocumented rest api call from watcher action
12:57:35 <dviroel> chandankumar: o/
12:57:41 <chandankumar> I was reviewing watcher apirefs doc and here is my observations: https://etherpad.opendev.org/p/watcher-apiref-audit based on comparison with watcher rest api, python-watcherclient and api refs docs.
12:58:16 <dviroel> on nice
12:59:13 <sean-k-mooney> yes so whewn i did a quick code review i did not check tf this also apples to any other endpoint
12:59:15 <chandankumar> thanks to sean-k-mooney analysis , We have few undocumented rest api which is not implemented
12:59:24 <dviroel> i need some time to go over everything that you have there
12:59:29 <sean-k-mooney> i would suggest checkign if we ahve an other formiding api actions and remvoe them also
13:00:05 <chandankumar> apart from that, we have very little docs around watcher cli
13:00:15 <chandankumar> sean-k-mooney: sure
13:00:30 <dviroel> chandankumar: which is the next bug in the list?
13:00:37 <chandankumar> yes correct
13:00:51 <dviroel> #link https://bugs.launchpad.net/watcher/+bug/2110897 - Add more docs around openstack optimize audit command in doc
13:00:56 <sean-k-mooney> the cli docs are generally auto generated form the help text
13:01:06 <chandankumar> audit command is commonly used, openstack optimize audit provides a way to update/cancel an audit
13:01:21 <chandankumar> but there is no reference in the docs.
13:01:50 <chandankumar> sean-k-mooney: It means Do we need to add examples in Cli docs? or more text there?
13:02:32 <sean-k-mooney> it depend
13:02:45 <sean-k-mooney> we doen generally add exampel of command output
13:03:28 <sean-k-mooney> if we look at server create as an exmaple https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/server.html#server-create
13:03:32 <chandankumar> Just added it in the doc
13:03:52 <chandankumar> Edit: just added command output in the bug
13:03:57 <sean-k-mooney> well im not really sure we need more docs
13:04:38 <sean-k-mooney> so the problem is https://docs.openstack.org/python-watcherclient/latest/cli/openstack_cli.html
13:04:45 <sean-k-mooney> shoudl be autogenerate based on the help text
13:04:52 <sean-k-mooney> but currently its not being auto generated
13:05:12 <sean-k-mooney> so the way to fix that is to make the doc not be static
13:05:51 <sean-k-mooney> so we shoudl be replacing https://github.com/openstack/python-watcherclient/blob/master/doc/source/cli/openstack_cli.rst?plain=1
13:06:10 <chandankumar> ah ok, let open a new bug to generate the cli docs automatically.
13:06:20 <sean-k-mooney> with autogenerate content we can likely look at other plugins for a reference on how to do that
13:06:39 <dviroel> right
13:06:40 <sean-k-mooney> for example barbican or manilla proably have examples of that
13:07:07 <dviroel> lets revisit this topic again next meeting chandankumar? if you could take a look on this debt
13:07:18 <chandankumar> dviroel: sure
13:07:33 <dviroel> chandankumar: tks
13:07:36 <chandankumar> I will bring it in next meeting, thank you dviroel sean-k-mooney !
13:07:58 <dviroel> #topic next meeting chair
13:08:09 <dviroel> if you want to be the chair next week
13:08:12 <dviroel> please add your name
13:08:16 <chandankumar> I will chair for the next meeting.
13:08:20 <dviroel> tks chandankumar
13:08:31 <dviroel> that's it
13:08:35 <dviroel> let's wrap up for today
13:08:39 <dviroel> we will meet again next week
13:08:42 <dviroel> thank you all for participating
13:08:47 <dviroel> #endmeeting