14:02:00 <jcapitao[m]> #startmeeting RDO meeting - 2023-05-31
14:02:00 <opendevmeet> Meeting started Wed May 31 14:02:00 2023 UTC and is due to finish in 60 minutes.  The chair is jcapitao[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:00 <opendevmeet> The meeting name has been set to 'rdo_meeting___2023_05_31'
14:02:11 <jcapitao[m]> #topic roll call
14:02:28 <jcapitao[m]> #chair amoralej spotz_
14:02:28 <opendevmeet> Current chairs: amoralej jcapitao[m] spotz_
14:02:33 <karolinku[m]> o/
14:02:40 <jcapitao[m]> #chair karolinku
14:02:40 <opendevmeet> Warning: Nick not in channel: karolinku
14:02:40 <opendevmeet> Current chairs: amoralej jcapitao[m] karolinku spotz_
14:03:20 <amoralej> i think you need the [m] in karolinku[m]
14:04:01 <jcapitao[m]> #chair karolinku[m]
14:04:01 <opendevmeet> Current chairs: amoralej jcapitao[m] karolinku karolinku[m] spotz_
14:05:44 <jcapitao[m]> the autocompletion in my Matrix client hides the [m]
14:07:17 <jcapitao[m]> let's start with first topic :)
14:07:26 <jcapitao[m]> #topic FIPS enabled C9S requires EMS in TLS negotiation to install software
14:08:12 <amoralej> that's mine
14:08:22 <amoralej> #link https://issues.redhat.com/browse/RDO-124
14:09:17 <amoralej> so, the summary is that a recent update in openssl in C9S has made that any fips enabled system can not install packages from repo servers without EMS negotiation
14:09:36 <amoralej> we have two cases related to RDO
14:10:14 <amoralej> trunk.rdoproject.org for RDO Trunk
14:10:32 <amoralej> repos.fedoraproject.org for rdo-release packages installing cloudsig repos
14:11:17 <amoralej> fips jobs running in upstream projects have hit this issue, i could workaround in devstack but we need to look for a better way
14:12:21 <amoralej> for trunk.r.o, i couldn't find a way to enable EMS in https with mod_ssl in centos7, so unless we can find some way, i think the solution will come with trunk.r.o migration to a newer OS
14:12:53 <amoralej> that's something we need to work with the infra team, i already discussed with apevec , but i guess it will take some time and planification
14:13:45 <amoralej> wrt repos.fedoraproject.org i think that the best we can do is to move those packages to some other place, as that's server is mainly an obsolete infra
14:14:24 <jcapitao[m]> and it's out of our control also
14:14:28 <apevec> yep, infra team will include this into backlog
14:14:58 <apevec> just wondering, do we really need that machine?
14:15:34 <jcapitao[m]> what was the reason to host rdo-release RPM on repos.fedoraproject.org ?
14:15:37 <apevec> it started as backup in AWS when the old rdocloud was unreliable
14:15:48 <amoralej> given that the url we use to install rdo-release is https://rdoproject.org/repos/rdo-release.el9.rpm my understanding is that we have some .htaccess to redirect the requests
14:16:12 <amoralej> jcapitao[m], to be able to install it in non centos servers
14:16:16 <apevec> ah are we talking about trunk.r.o or repos.fpo?
14:16:30 <amoralej> apevec, both, right now repos.fpo
14:16:36 <amoralej> but we can go back to trunk.r.o later
14:16:39 <apevec> repos.fpo is legacy
14:17:01 <apevec> and we should just abandon it
14:17:38 <amoralej> i think the best option is to simply ship those rpm from www.rdoproject.org itself
14:17:46 <amoralej> as we already depend on it for the redirect
14:17:58 <jcapitao[m]> yeah +1
14:18:00 <amoralej> we may even maintain the same urls
14:18:11 <amoralej> so, no impact for users
14:19:12 <apevec> yep
14:19:40 <spotz_> nice
14:19:50 <amoralej> bth, i have no idea how is that configured, i don't see anything in rdo-website repo
14:20:04 <amoralej> that maintains any redirect or something
14:20:06 <apevec> yeah I wonder how we manage that .htaccess
14:20:27 <amoralej> it may be in the ansible which maintains the webserver
14:20:40 <amoralej> so any volunteer to dig on it? :)
14:20:42 <jcapitao[m]> it rings me a bell
14:21:36 <jcapitao[m]> I can work on it
14:21:43 <amoralej> thanks jcapitao[m]
14:22:08 <amoralej> #action jcapitao will investigate on how to move rdo-release rpms to rdoproject.org server
14:22:18 <amoralej> wrt trunk.r.o, back to apevec question
14:23:15 <amoralej> i think having a separate server has two pros:
14:23:33 <amoralej> 1. having two servers able to serve repos in case one fails (i mean trunk-centos8.r.o and trunk.r.o)
14:24:33 <amoralej> 2. serving content and api is more critical that building so splitting both functions is useful so that we can do maintenances in the builder with no impact in the server
14:24:50 <amoralej> also in terms of avoiding the builder impacts in the server
14:25:13 <amoralej> said this, we may move trunk.r.o to the same infra as trunk-centos8
14:25:38 <amoralej> although having different infra providers is also a good thing in terms of reliability
14:27:09 <jcapitao[m]> makes sense
14:27:50 <jcapitao[m]> the con is maintenance and cost :)
14:28:51 <spotz_> Hey I can design us a totally redundant infrastructure but they are quite $$$$$:)
14:28:53 <amoralej> yes
14:29:30 <amoralej> currently, we have two systems in aws, i have no idea about cost
14:29:59 <amoralej> said this, this is something to discuss with infra team
14:30:20 <amoralej> they are probably the best informed for this decission
14:30:40 <spotz_> Yeah and the ones to maintain it
14:30:51 <jcapitao[m]> right
14:31:25 <amoralej> so, i think this is it about this topic
14:31:44 <jcapitao[m]> ok thank you
14:31:48 <jcapitao[m]> let's move to next topic
14:31:55 <jcapitao[m]> #topic pyproject-macros POC
14:32:04 <karolinku[m]> that's mine
14:32:17 <karolinku[m]> you can find detailed etherpad here: https://review.rdoproject.org/etherpad/p/pyproject_macros_reqs_generations_POC
14:32:26 <karolinku[m]> but tl;dr: we need both BR and Requirements to calculate proper order by dlrn, so we need a file (or other kind of input) with list of Total BR and Total Requirements. My hopes are to use rpmbuild to manage spec BR and pyproject macros to manage requirements from source code. Hopes are under verification now.
14:33:12 <karolinku[m]> if that works, then: yes, we could remove Requires  from spec
14:33:23 <karolinku[m]> I mean - that's possible
14:33:31 <karolinku[m]> but not BR's
14:33:49 <amoralej> it'd be cool if we can get all the requirements without running rpmbuild, only by running macros
14:34:39 <karolinku[m]> I don't think that's possible. In my glance example, there is BR which is not defined in source code
14:34:47 <karolinku[m]> so it's not catched by macros
14:35:03 <amoralej> but those will need to be added as BuildRequires in the spec
14:35:16 <amoralej> so we can parse the spec file without running rpmbuild
14:36:18 <amoralej> my point aginst running rpmbuild at that point is that it will be more difficult to integrate it in dlrn and would make it much slower
14:36:48 <karolinku[m]> why slower?
14:37:42 <amoralej> because it would need to run the rpmbuild command for each package at the beginning only to calculate the order, then order it, then build the packages
14:38:13 <karolinku[m]> -br option is a quick way to  parse BRs from spec file, which skips phases of building binaries
14:38:52 <amoralej> and at the end, iiuc, there is no big win of running rpmbuild vs finding the BRs in the spec file directly, or there is?
14:39:18 <karolinku[m]> rpmbuild is understanding comditions, grep not
14:39:42 <amoralej> and rpmspec ?
14:40:00 <karolinku[m]> it is too
14:40:22 <karolinku[m]> understans conditions too
14:41:47 <karolinku[m]> It would be great to use just one tool, but at this moment i'm not sure how to encourage macros to produce nice output and parse BR from specs
14:41:48 <amoralej> so if we don't use automated BRs, running with -br would be pretty fast but if we do automatic BRs, it takes some time to process
14:42:25 <amoralej> let's split in two, running macros from one side, and parsing spec in the other
14:42:34 <amoralej> at the end we'd need to join both
14:43:18 <amoralej> yep, one of the challenges is how to get a nice output from the macro
14:43:58 <amoralej> but, i guess it must be some way as it's what package build does
14:44:02 <amoralej> when using macros
14:44:24 <amoralej> it'd be good to check if those macros are doing something else apart from displaying in stdout
14:44:35 <karolinku[m]> im afraid thats it can be installed "on the fly"
14:44:41 <amoralej> maybe it's able to write the spec or something
14:45:48 <karolinku[m]> I mean: found missining BR -> install -> move to another BR check, but need to confirm, but looks like so
14:47:10 <amoralej> i see, we need to confirm
14:47:35 <karolinku[m]> what concerns me about macros:
14:47:35 <karolinku[m]> > _If pyproject.toml is not found, the macros automatically fall backs to using setuptools with configuration in setup.cfg/setup.py._
14:48:16 <karolinku[m]> that's why im not sure if it looking at BR in spec
14:48:26 <amoralej> actually that's what will happen in openstack packages
14:49:05 <amoralej> but setup.cfg/setup.py will load requirements from requirements.txt
14:49:19 <amoralej> actually we can also look to use the tox option
14:49:22 <karolinku[m]> yes, it will
14:49:30 <amoralej> which is what we used in the glance review
14:49:48 <amoralej> well, at the end it will look for setup.cfg/setup.py
14:49:48 <karolinku[m]> sure, but it is still not BR
14:49:56 <amoralej> wdym?
14:50:13 <amoralej> i'm not following you now
14:50:25 <karolinku[m]> systemd in glance is this special kind of requirement, which is not mentioned in any requirement.txt file,  setup.cfg/setup.py or any other
14:50:39 <amoralej> yeah, we will always need to consume that from the spec
14:50:55 <amoralej> any non-python dep has to go from explicit BR in the spec
14:51:01 <amoralej> can't be automated
14:51:42 <amoralej> tbh, in most cases those will not affect to the order, but in any case we need to have both automatic and explicit BRs into account
14:51:46 <karolinku[m]> yes, that's why it is so importat  to not to cut out rpmbuild/rpmspec from the beginning, because we may be not able to parse spec BR with macros
14:52:00 <amoralej> i'm not cutting rpmspec, only rpmbuild :)
14:52:41 <amoralej> actually, we will not be able to parse spec br with macros
14:53:00 <amoralej> but tbh, that's the easy part imo
14:53:36 <amoralej> actually, rpmbuild is an option, but i think it should be just a last resort
14:55:46 <jcapitao[m]> that was a good discussion here
14:55:59 <jcapitao[m]> I need to move to next and last topic because we have 5min left
14:56:46 <jcapitao[m]> #topic openstack clients on EPEL9
14:56:53 <amoralej> we can continue working about this after the mtg
14:57:01 <amoralej> i mean pyproject macros
14:57:16 <jcapitao[m]> yeah sure
14:57:34 <jcapitao[m]> #info openstack clients and dependencies are being built currently
14:57:49 <jcapitao[m]> you may have seen some BZ tickets operations
14:58:15 <amoralej> there still many packages pending to build ?
14:58:22 <jcapitao[m]> I scripted all that and will handle them as low prio
14:58:53 <jcapitao[m]> amoralej: yes, but huge effort has been produced since a year now to build packages on EPEL9
14:59:26 <jcapitao[m]> so now there are only more or less openstack packages to build
15:00:19 <amoralej> ok
15:00:27 <jcapitao[m]> #topic next chair
15:00:38 <jcapitao[m]> who's willing to chair next week ?
15:01:21 <amoralej> i can take it
15:01:52 <jcapitao[m]> #action amoralej will chair next week
15:02:05 <jcapitao[m]> thank you
15:02:20 <jcapitao[m]> #topic open floor
15:02:51 <jcapitao[m]> if you have something to bring on before I close the mtg
15:03:05 <spotz[m]> And remember next week is video
15:03:28 <jcapitao[m]> right
15:03:52 <amoralej> nothing from my side
15:04:58 <jcapitao[m]> I'm going to close the mtg
15:04:58 <jcapitao[m]> thank you all for joining
15:05:06 <jcapitao[m]> #endmeeting