14:00:23 <spotz_> #startmeeting RDO meeting - 2023-05-17
14:00:23 <opendevmeet> Meeting started Wed May 17 14:00:23 2023 UTC and is due to finish in 60 minutes.  The chair is spotz_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:23 <opendevmeet> The meeting name has been set to 'rdo_meeting___2023_05_17'
14:00:29 <spotz_> #topiv Roll Call
14:00:35 <spotz_> #topic Roll Call
14:01:33 <karolinku[m]> o/
14:01:42 <spotz_> #chair karolinku[m]
14:01:42 <opendevmeet> Current chairs: karolinku[m] spotz_
14:01:50 <amoralej> o/
14:02:16 <spotz_> #chair amoralej
14:02:16 <opendevmeet> Current chairs: amoralej karolinku[m] spotz_
14:02:27 <jcapitao[m]> o/
14:02:38 <spotz_> #chair jcapitao[m]
14:02:38 <opendevmeet> Current chairs: amoralej jcapitao[m] karolinku[m] spotz_
14:02:42 <spotz_> #link https://etherpad.opendev.org/p/RDO-Meeting
14:02:49 <spotz_> Agenda ^
14:02:52 <evallesp> #chair evallesp
14:03:04 <evallesp> o/
14:04:38 <spotz_> #chair evallesp
14:04:38 <opendevmeet> Current chairs: amoralej evallesp jcapitao[m] karolinku[m] spotz_
14:04:42 <spotz_> Welcome evallesp!
14:04:56 <evallesp> :)
14:05:05 <spotz_> #topic Enabling signing for the packages tagged in testing ?
14:05:22 <spotz_> #link https://lists.centos.org/pipermail/centos-devel/2023-May/142901.html
14:05:41 <jcapitao[m]> I submitted this topic
14:05:55 <spotz_> Go for it:)
14:06:43 <jcapitao[m]> so signing -testing packages is "live" since May 15th
14:07:01 <amoralej> so, iiuc that means the packages in buildlogs are now signed, right?
14:07:01 <jcapitao[m]> all the packages that are now tags to -testing are signed
14:07:10 <jcapitao[m]> example: https://paste.centos.org/view/cbbb1675
14:07:26 <jcapitao[m]> we tagged openstack-barbican-16.0.0-2 to -testing this morning
14:07:36 <jcapitao[m]> and it's signed
14:08:08 <amoralej> and the packages which were in the tags previously?
14:08:14 <amoralej> are now signed?
14:08:23 <jcapitao[m]> they are not :)
14:08:39 <amoralej> so ....
14:08:43 <jcapitao[m]> but arrfab says we can ask infra team by creating a ticket
14:09:07 <jcapitao[m]> they can do as a one shot operation
14:09:29 <amoralej> mmm i'm not sure
14:09:30 <amoralej> tbh
14:09:33 <rdogerrit> Chandan Kumar proposed config master: Fix the var name for content_provider_registry_ip  https://review.rdoproject.org/r/c/config/+/48648
14:10:05 <amoralej> so, we may ask to sign all the packages and enable gpgcheck in centos-release-openstack-* for -testing repo
14:10:26 <jcapitao[m]> yes
14:10:29 <amoralej> we don't use it too much
14:10:52 <amoralej> but ok, if someone wants to use signed from -testing, they could
14:11:06 <amoralej> improving security is never a bad thing
14:11:08 <jcapitao[m]> yeah that's my interrogation
14:11:30 <jcapitao[m]> whether or not we should set gpgcheck to 1 as default
14:11:38 <amoralej> although i don't see it as a big advantadge anyway, as users should be using -release repos usually
14:11:58 <amoralej> but, yeah, the good part is that is backwards compatible
14:12:15 <amoralej> we will not break anyone by asking to sign the packages
14:12:35 <amoralej> that way, also, users my select if they want to enable gpgcheck or not
14:13:53 <jcapitao[m]> so you think we should ask signing and let gpgcheck to 0 ?
14:15:06 <amoralej> i'd say to ask signing first, and once we have it signed, we can decide :)
14:15:19 <amoralej> but in any case, users may enable by themselves tgoo
14:15:20 <amoralej> too
14:15:40 <jcapitao[m]> right
14:15:44 <rdogerrit> Merged config master: Fix the var name for content_provider_registry_ip  https://review.rdoproject.org/r/c/config/+/48648
14:16:06 <spotz_> Makes sense
14:17:07 <jcapitao[m]> I'll request the infra team for the maintained Cloud SIG repos
14:17:10 <amoralej> jcapitao[m], only for antelope or for all the currently supported?
14:17:17 <amoralej> ack, so for all
14:18:59 <jcapitao[m]> #action jcapitao to create centos-infra ticket requesting signing for testing repos
14:20:04 <jcapitao[m]> that's it for this topic I guess :)
14:20:55 <spotz_> Moving on then!
14:21:12 <spotz_> #topic pyproject macros
14:21:25 <spotz_> amoralej: I'm assuming this was you?
14:21:58 <amoralej> yes
14:22:24 <amoralej> so, i was preparing stuff for the migration to pyproject and automatic brs and requires and something came to my mind
14:22:39 <amoralej> if we remove the buildrequires from specs, how do we bootstrap next releases?
14:22:48 <amoralej> specifically how to determine the order
14:22:57 <amoralej> dlrn --order relies on BuildRequires in specs
14:23:19 <amoralej> so, i need us to consider options and alternatives i may be missing
14:23:53 <amoralej> dunno if i'm explaining the issue clear enough
14:24:30 <jcapitao[m]> damn
14:25:19 <jcapitao[m]> could we set up a POC with DLRN and bunch of new SPECs ?
14:25:32 <amoralej> but, what we'd test?
14:25:48 <karolinku[m]> is is possible to generate BR list before build attempt?
14:25:53 <amoralej> i mean, it's clear --order will do nothing if there are no BRs
14:25:54 <jcapitao[m]> the first 5 packages of the DLRN order
14:26:15 <amoralej> karolinku[m], that's an option i've been thinking about
14:26:44 <amoralej> that dlrn uses the same code that rpmbuild use to generate automatically the BRs and feed that to dlrn
14:27:07 <amoralej> by running the same macros or something like that
14:27:25 <amoralej> but i see it pretty complicated, tbh
14:27:40 <amoralej> but yes, that's a path to investigate
14:28:33 <karolinku[m]> I can take a look at this tomorrow
14:29:02 <amoralej> https://github.com/softwarefactory-project/DLRN/blob/master/dlrn/shell.py#L385-L424
14:29:12 <amoralej> that's where dlrn generates the order
14:30:09 <amoralej> together with https://github.com/softwarefactory-project/DLRN/blob/6bcaaecd1b18ffb49ed262fca4e6167a31edb44d/dlrn/rpmspecfile.py#L110
14:30:20 <amoralej> other options would be:
14:30:57 <amoralej> 1. not using --order and setting manually the order in the bootstrap
14:31:25 <amoralej> 2. getting the order from other repo, i.e. from centos9-master dlrn repo when creating centos9-bobcat
14:31:58 <amoralej> 3. Do not remove explicit BRs but also enable automatic BRs for new stuff
14:32:25 <amoralej> 4. Manage BRs manually and not enable automatic at all but enable automation for runtime requires
14:32:58 <amoralej> 5. Make dlrn gets the BRs automatically before starting the builds (what karolinku[m] mentioned)
14:33:03 <amoralej> that what comes to my mind
14:33:45 <karolinku[m]> 3. looks like win - win, isn't it?
14:34:19 <amoralej> at some point explicit BRs may be wrong and miss automatic ones, so next --order would be incorrect
14:34:20 <spotz_> seeing manually in 4 doesn't look like a good option except maybe for the first few runs
14:35:22 <amoralej> with 3. we made a tradeoff between automation and accuracy of BRs
14:35:25 <jcapitao[m]> we have to make 5) to work
14:35:51 <amoralej> i'm thinking with 5 we have two sub-options :)
14:35:57 <jcapitao[m]> I think 3 would be a mess it several months
14:36:14 <amoralej> 5.1 Automate BRs generation in dlrn using pyproject macros
14:37:10 <amoralej> 5.2 Automate BRs generation using our own tooling wich would work for openstack standards and would read requirements.txt and test-requirements.txt
14:37:24 <amoralej> but tbh, this is going to be hard in any case
14:37:55 <amoralej> i.e. in some packages we don't have BRs for all the packages which are in test-requirements...
14:38:09 <amoralej> meh
14:38:30 <jcapitao[m]> ah right..
14:38:55 <amoralej> well, let's see if we are able to run the macros "in an standalone way"
14:39:29 <amoralej> but using the same configuration that is actully in the spec
14:39:42 <amoralej> it should run %prep ...
14:40:01 <amoralej> and all that
14:40:08 <amoralej> i'm not optimistic
14:41:21 <amoralej> option 4 could also be a good compromise, as maintenance of buildrequires is low compared with runtime requires
14:41:24 <spotz_> I guess we'll learn more on how to proceed when you try
14:41:39 <jcapitao[m]> yeah
14:41:48 <amoralej> and in any case, it would save us of running the release-preparation reqcheck
14:41:52 <jcapitao[m]> I like 4 too
14:42:07 <jcapitao[m]> maybe we should migrate in 2 steps
14:42:26 <jcapitao[m]> runtime first and then build time
14:42:29 <spotz_> 4 will let us know how much if anything can be automated later
14:42:32 <karolinku[m]> yeah, but it won't make us free from doing reqchecks with every new release
14:42:40 <amoralej> in any case, i agree in try first and see what we can learn
14:42:53 <amoralej> yep, that's a good point spotz_
14:42:58 <amoralej> karolinku[m], no no
14:43:01 <amoralej> it will
14:43:10 <karolinku[m]> partially
14:43:14 <amoralej> remember reqchecks are for Requires, not BuildRequires
14:43:23 <amoralej> well... mostly :)
14:43:40 <amoralej> we update BRs mainly when there are FTBFS
14:44:01 <jcapitao[m]> we tend to update BR too during reqcheck but not mandatory
14:44:07 <amoralej> otherwise, we even do not realize we are missing BRs unless we are also missing requires
14:44:08 <jcapitao[m]> except if it FTBFS
14:44:20 <amoralej> yes, but if we don't need to update requires
14:44:35 <amoralej> what'd be the point of updating BRs if packages build successfully?
14:45:12 <jcapitao[m]> indeed
14:45:46 <spotz_> FYI we're at 15 minutes left with 1 more topic
14:45:59 <amoralej> yeah, let's continue digging into this
14:46:24 <amoralej> karolinku[m], let's sync tomorrow
14:46:35 <amoralej> let me add an info
14:46:43 <amoralej> before moving on to next topic
14:47:22 <amoralej> #info removing explicit BuildRequires from specs as part of the automation would break the --order feature in dlrn
14:48:06 <spotz_> good?
14:48:08 <amoralej> #action karolinku will check if we can use pyproject macros in an standalone mode and use those automatic BRs to compute bootstrap order
14:48:11 <amoralej> now :)
14:48:21 <spotz_> #topic Enhance monitoring system
14:48:30 <spotz_> Not sure who this belongs to
14:48:35 <evallesp> Me
14:48:57 <spotz_> Go for it:)
14:49:29 <evallesp> This is about how we're monitoring "stuck" process in DLRN. Currently we're checking if there's a new build created in the previous 24 hours.
14:49:41 <evallesp> This made some false-positive mainly Monday days.
14:49:52 <amoralej> spotz_ evallesp is part of the infra/tools meeting and is working in the dlrn infra
14:50:24 <amoralej> s/meeting/team/
14:50:57 <spotz_> Welcome:)
14:51:13 <evallesp> So, by creating a cronjob that executes a python script to collect the modification time for the latest dlrn-run.*.log and save the date into the node-exporter in prometheus, would allow us to know more properly if the process is stuck.
14:51:19 <amoralej> and the monitoring he mentions is https://prometheus.monitoring.softwarefactory-project.io/prometheus/alerts
14:51:34 <evallesp> Thanks to both!
14:51:54 <evallesp> so the idea is to expose for each builder a metric: dlrn_last_update with the builder name as index.
14:52:34 <amoralej> so the idea would be to monitor that there are newer dlrn-run*log that a certain time instead of new builds?
14:53:03 <evallesp> That's it. take the modification time and check if older than 7200 seconds.
14:54:13 <spotz_> Sounds relatively easy and straightforward for a solution
14:54:32 <amoralej> lgtm and more accurate that new builds, specially for old releases
14:54:57 <spotz_> If it happens no patches need to be built will we touch a blank log file?
14:55:04 <jcapitao[m]> +1
14:55:17 <evallesp> the log is created anyway.
14:55:22 <evallesp> so no alarm would be triggered
14:56:12 <spotz_> Ok sweet
14:57:04 <spotz_> So sounds like there's a greement on this?
14:57:23 <amoralej> do we have some ansible role or something where we install and configure node-exporter ?
14:57:43 <amoralej> i understand we'll need to install some script or something
14:57:47 <evallesp> yes, we have a role to deploy the node-exporter.
14:58:02 <amoralej> we'll include it in that same role or in dlrn role?
14:58:16 <evallesp> and we have to create a role to deploy a python script executable for any user that writes where node-exporter checks the info in the Prometheus format.
14:58:35 <evallesp> I'd say in the sf-infra repo, instead of DLRN.
14:58:44 <evallesp> https://softwarefactory-project.io/r/plugins/gitiles/software-factory/sf-infra
14:58:59 <evallesp> node-exporter: https://softwarefactory-project.io/r/plugins/gitiles/software-factory/sf-infra/+/refs/heads/master/roles/service/node-exporter/
14:59:23 <evallesp> the rules to be changed: https://softwarefactory-project.io/r/plugins/gitiles/software-factory/sf-infra/+/refs/heads/master/monitoring/rules-dlrn.yaml
15:00:42 <amoralej> sounds good
15:01:26 <evallesp> and the role would be implemented here: https://softwarefactory-project.io/r/plugins/gitiles/software-factory/sf-infra/+/refs/heads/master/playbooks/site_dlrn.yaml (I'm not 100% sure about this yet)
15:01:37 <evallesp> s/implemented/imported
15:01:39 <spotz_> Any thing else on this?
15:01:47 <evallesp> Not from me.
15:02:00 <spotz_> Ok next real quick
15:02:10 <spotz_> #topic Chair for Next Week
15:02:16 <spotz_> Ay volunteers?
15:02:36 <amoralej> o/
15:02:54 <spotz_> Thanks amoralej
15:03:24 <spotz_> Anyone have anything else? We're at 3 minutes over
15:03:45 <spotz_> #endmeeting