14:03:30 <karolinku[m]> #startmeeting RDO meeting - 2023-09-13
14:03:30 <opendevmeet> Meeting started Wed Sep 13 14:03:30 2023 UTC and is due to finish in 60 minutes.  The chair is karolinku[m]. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:30 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:03:30 <opendevmeet> The meeting name has been set to 'rdo_meeting___2023_09_13'
14:03:37 <amoralej> o/
14:03:39 <spotz[m]> o/
14:03:54 <jcapitao[m]> o/
14:04:01 <rlandy_> o/
14:04:15 <karolinku[m]> #chair amoralej spotz jcapitao[m] rlandy_
14:04:15 <opendevmeet> Warning: Nick not in channel: spotz
14:04:15 <opendevmeet> Current chairs: amoralej jcapitao[m] karolinku[m] rlandy_ spotz
14:04:36 <karolinku[m]> #chair spotz[m]
14:04:36 <opendevmeet> Current chairs: amoralej jcapitao[m] karolinku[m] rlandy_ spotz spotz[m]
14:06:14 <karolinku[m]> ok, lets start with first topic
14:06:20 <karolinku[m]> #topic RDO bobcat 2023.2 preparation
14:07:44 <jcapitao[m]> I'm gonna put the links
14:07:58 <jcapitao[m]> #link https://issues.redhat.com/browse/RDO-135
14:08:09 <jcapitao[m]> #link https://review.rdoproject.org/r/q/topic:bobcat-branching
14:08:19 <jcapitao[m]> #link https://review.rdoproject.org/etherpad/p/bobcat-release-preparation
14:08:34 <jcapitao[m]> #info the clients and libs are built
14:08:55 <jcapitao[m]> #info RC1 bits are WIP upstream
14:09:14 <jcapitao[m]> https://review.opendev.org/q/topic:bobcat-rc1-deadline
14:09:48 <jcapitao[m]> so we are currently synced to upstream
14:10:47 <jcapitao[m]> maybe we can anticipate by pinning the non-Openstack puppet modules
14:11:01 <jcapitao[m]> but maybe it's too early
14:11:11 <amoralej> yep, actually that's connected with third topic
14:11:42 <amoralej> i planned to propose to pin them now also as part of moving to new model for non-openstack puppet modules
14:12:15 <jcapitao[m]> okk so let's discuss this afterward then
14:12:47 <jcapitao[m]> that's it for Bobcat/2023.2 release preparation
14:13:19 <karolinku[m]> ok
14:13:27 <karolinku[m]> moving forward to
14:13:33 <karolinku[m]> #topic Stop RDO Trunk repos for centos8-[train,ussuri,victoria] ?
14:14:15 <amoralej> #info projects are EOLing stable branches specially for train, but also ussuri and victoria
14:14:31 <rlandy_> here to discuss ^^
14:14:34 <amoralej> soon, puppet and neutron will EOL them too
14:14:48 <spotz[m]> Welcome rlandy_
14:14:52 <rlandy_> train teardown is in progress on the tripleo side
14:15:02 <rlandy_> also we will lose puppet support
14:15:12 <rdogerrit> Francesco Pantano proposed rdo-infra/ansible-role-dlrn master: Bump ceph repo to Reef  https://review.rdoproject.org/r/c/rdo-infra/ansible-role-dlrn/+/49997
14:15:17 <amoralej> also TripleO CI is planning to stop running ci so i guess tripleo may also EOL it
14:15:37 <rlandy_> once we get the plan to move FFU job downstream (Thursday meeting). we will merge pending teardown patches
14:15:57 <rlandy_> no expectation that any upstream commits will come in on the train side for any tripleo repo now
14:16:08 <rdogerrit> Francesco Pantano proposed rdo-infra/ansible-role-dlrn master: Bump ceph repo to Reef  https://review.rdoproject.org/r/c/rdo-infra/ansible-role-dlrn/+/49997
14:16:16 <amoralej> you know if tripleo also will EOL the stable/train branch?
14:16:30 <amoralej> or will leave it around just without CI?
14:16:48 <rlandy_> idk ... would put that to the DF people
14:16:53 <rlandy_> up to them
14:17:17 <amoralej> ok, anyway
14:17:18 <rlandy_> we are just killing check/gate/integration/component testing
14:18:00 <amoralej> so, i'd say the plan would be to wait for TripleO CI to remove all CI jobs
14:18:15 <rlandy_> give me a week
14:18:16 <amoralej> then stop the builder
14:18:20 <amoralej> sure, np
14:18:43 <rlandy_> I will put the patches up for review on Friday
14:18:43 <amoralej> actually, we will maintain the repos as-is for some time
14:19:26 <amoralej> #info TripleO CI team is removing all the TripleO jobs running stable/train code
14:20:52 <amoralej> #info the proposal is to stop the RDO Trunk Train builder after CI team confirms jobs are not longer running. By then, we will maintain the repos in the server in its latest status
14:20:59 <amoralej> #undo
14:20:59 <opendevmeet> Removing item from minutes: #info the proposal is to stop the RDO Trunk Train builder after CI team confirms jobs are not longer running. By then, we will maintain the repos in the server in its latest status
14:21:03 <rdogerrit> Marios Andreou proposed rdo-jobs master: Adds a force_job_failure post-playbook for data plane adoption  https://review.rdoproject.org/r/c/rdo-jobs/+/49970
14:21:30 <amoralej> #info the proposal is to stop the RDO Trunk Train builder after CI team confirms jobs are not longer running. By then, we will maintain the repos in the server in its latest status for a couple of weeks
14:22:39 <amoralej> #info after removing Train we will also follow the same process for Ussuri and Victoria
14:23:26 <amoralej> sounds good?
14:23:34 <jcapitao[m]> +1
14:23:49 <jcapitao[m]> note that for Ussuri we've already stopped promotions
14:23:56 <spotz[m]> +1
14:25:11 <amoralej> ok, we will review the status in next meeting then
14:25:52 <jcapitao[m]> thanks for the heads-up rlandy_
14:26:22 <amoralej> thanks for joining rlandy_ !
14:27:04 <amoralej> btw, removing train means we can remove the old centos7 builder, as train is the last release built for centos7
14:27:49 <rlandy_> sure ... thank you
14:28:50 <jcapitao[m]> amoralej: when we remove the definitions in sf-infra repo it doesn't remove the data IIRC right ?
14:29:19 <amoralej> nop, removal requires manual task
14:29:34 <jcapitao[m]> ok
14:29:38 <amoralej> i mean content removal
14:29:48 <amoralej> stopping the builder can be done via sf-infra review
14:30:21 <jcapitao[m]> maybe we should keep serving the content, and remove the home directory of the builders
14:30:49 <amoralej> btw, we need to check devstack support for those releases and if they are consuming RDO repos for deployment on centos
14:31:27 <amoralej> well content is in the home directories, so we'll need to keep while we want to serve the content
14:32:23 <spotz[m]> How's it going with packstack?
14:33:01 <jcapitao[m]> ah right
14:33:01 <amoralej> you mean wrt train removal?
14:33:14 <amoralej> we should EOL the branches too, right
14:33:54 <spotz[m]> In general, if we're EOLing stuff we should remove them from there to. But has anyone tested bobcat?
14:34:41 <amoralej> yes, we run periodic jobs with packstack and master
14:34:58 <amoralej> so that should work fine in bobcat too
14:35:05 <jcapitao[m]> yep, the status is ok
14:37:15 <amoralej> so, i think this is it for this topic
14:38:21 <karolinku[m]> can we move to another topic?
14:38:25 <amoralej> i'd say so
14:38:39 <jcapitao[m]> yes I think
14:39:12 <karolinku[m]> #topic Changing puppet modules management for non-openstack modules (from chasing trunk to upstream Puppetfile)
14:41:18 <amoralej> historically, RDO has been following master trunk commits for non-openstack puppet modules, while upstream puppet openstack modules have been following latest tags via puppetfile
14:41:45 <amoralej> this means RDO is ahead what has led to issues from time to time (recently with puppet-firewall)
14:42:42 <amoralej> we have applied pins to known good hashes when having this issues but there have discussions about changing this to a new model where we use the same versions and upstream does
14:43:02 <spotz[m]> Sorry having internet issues here
14:43:03 <amoralej> that would be also consistent with the approach we follow for python libraries with upper-constraints file
14:43:07 <amoralej> np spotz[m]
14:44:41 <amoralej> so, i'd bet for moving to that approach by implementing some automation that proposes reviews to update source-branch in rdoinfo sync to upstream Puppetfile https://github.com/openstack/puppet-openstack-integration/blob/master/Puppetfile
14:45:36 <jcapitao[m]> +1
14:45:52 <amoralej> as pointed by tkajinm in https://etherpad.opendev.org/p/RDO-Meeting the main issue is transition and downgrades
14:47:11 <amoralej> so i'd say what we could do is
14:47:36 <amoralej> 1st pin bobcat-uc to last promotion commits (when commit matches a tag, use the tag to match what we have in the puppetfile)
14:49:06 <amoralej> 2nd create an script that compares versions in puppetfile with source-branch. Only if version in puppetfile is > pin, propose an update in rdoinfo
14:49:55 <jcapitao[m]> to avoid downgrade
14:49:57 <amoralej> 3rd add that script to the existing update-uc job so we would use the same job to update both python and puppet packages
14:50:01 <amoralej> yes
14:50:23 <jcapitao[m]> and 3rd is to avoid having merge conflict
14:50:26 <amoralej> so, initially we'd maintain the latest known good versions, but when p-o-i moves ahead we will sync to it
14:50:30 <amoralej> yes
14:50:43 <amoralej> so, we will converge over time without downgrade
14:51:15 <jcapitao[m]> sounds good a plan
14:51:44 <amoralej> lemme ad some info to the meeting minutes
14:52:19 <amoralej> #info RDO has been following master trunk commits for non-openstack puppet modules, while upstream puppet openstack modules have been following latest tags via puppetfile which has lead to issues from time to time
14:53:07 <rdogerrit> Merged rdo-jobs master: Fixes needed for downstream data-plane-adoption job standup  https://review.rdoproject.org/r/c/rdo-jobs/+/49473
14:53:58 <amoralej> #info RDO has mechanism to pin puppet modules to known good hashes when having issues but following the same tags as upstream would reuse upstream tests and would be more consistent with the approach we follow for python libraries with upper-constraints file
14:56:20 <amoralej> #info in order to avoid downgrades from the current packages, we could pin to latest promoted hashes in puppet promotion pipeline and implement automation to compare the versions in upstream puppetfile and rdoinfo. Only if version in puppetfile is > rdoinfo pin, send a review to update it. initially we'd maintain the latest known good versions, but when p-o-i moves ahead  we will converge over time without downgrade
14:56:34 <amoralej> i think i've summarize it :)
14:57:01 <amoralej> jcapitao[m], you had that script to propose pins based on a promoted repo, right?
14:57:17 <jcapitao[m]> yes
14:57:36 <jcapitao[m]> described in https://issues.redhat.com/browse/RDO-146
14:58:03 <amoralej> so, i'd say we can start by pinning asap
14:58:40 <jcapitao[m]> good summary
14:58:53 <amoralej> #action amoralej to send the pin review for puppet modules
14:59:20 <amoralej> note, we may delay a bit the branching and build in case upstream still updates any module to something newer that current pin
14:59:40 <amoralej> so no need to branch right now
15:00:07 <amoralej> actually we should create a jira ticket for the new automation
15:01:05 <amoralej> and i think that's it wrt this topic, we are out of time
15:01:33 <jcapitao[m]> I'll update the Jira card mentioned above
15:03:46 <amoralej> but let's keep separated the task to pin for bobcat and the one for automation
15:04:37 <jcapitao[m]> ahh ok
15:04:45 <jcapitao[m]> sorry I misunderstood
15:04:49 <jcapitao[m]> so yeah I'll create one
15:06:50 <amoralej> i think we can move on to next topic?
15:07:14 <karolinku[m]> #topic next chair
15:07:45 <karolinku[m]> who would like to chair next mtg?
15:07:57 <amoralej> i can do it
15:08:16 <karolinku[m]> #action amoralej is chairing next week
15:08:24 <karolinku[m]> #topic open floor
15:08:48 <rdogerrit> Merged rdoinfo master: Promote CBS tags update for antelope-9s-release  https://review.rdoproject.org/r/c/rdoinfo/+/49549
15:09:13 <jcapitao[m]> ^ finally :)
15:09:34 <jcapitao[m]> nothing else to bring on my side
15:09:45 <amoralej> nothing from me
15:09:52 <karolinku[m]> im closing the meeting. sorry fora delay!
15:10:01 <karolinku[m]> #endmeeting