14:00:35 <amoralej> #startmeeting RDO meeting - 2021-09-15 14:00:35 <opendevmeet> Meeting started Wed Sep 15 14:00:35 2021 UTC and is due to finish in 60 minutes. The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:35 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:35 <opendevmeet> The meeting name has been set to 'rdo_meeting___2021_09_15' 14:00:50 <amoralej> #topic roll call 14:02:04 <amoralej> ykarel|afk, jcapitao spotz around? 14:02:13 <spotz> o/ 14:02:19 <jcapitao> o/ 14:02:29 <marios> o/ hi 14:02:39 <amoralej> #chair spotz jcapitao marios 14:02:39 <opendevmeet> Current chairs: amoralej jcapitao marios spotz 14:02:47 <apevec[m]> o/ half here/there 14:03:23 <amoralej> #chair apevec[m] 14:03:23 <opendevmeet> Current chairs: amoralej apevec[m] jcapitao marios spotz 14:03:29 <jpena> o/ (also multi-booked) 14:03:36 <amoralej> #chair jpena 14:03:36 <opendevmeet> Current chairs: amoralej apevec[m] jcapitao jpena marios spotz 14:03:39 <rdogerrit> Lee Yarwood created rdoinfo master: Bump python-alembic to 1.5.5 https://review.rdoproject.org/r/c/rdoinfo/+/35545 14:03:48 <amoralej> #topic Status of Xena GA Preparation 14:04:04 <amoralej> #link https://trello.com/c/ofx2cKjc/760-xena-release-preparation 14:04:22 <amoralej> #link https://review.rdoproject.org/r/#/q/topic:xena-branching 14:04:24 <amoralej> jcapitao, all yours 14:04:42 <jcapitao> so we built non client and client libraries 14:05:07 <amoralej> #info non-client and client libraries built 14:05:08 <jcapitao> we are at RC1 target week 14:05:26 <jcapitao> now we're finalizing the reqcheck of core project and we'll be able to build them by the end of the week 14:05:42 <amoralej> good 14:06:13 <amoralej> no known blockers right? 14:06:34 <jcapitao> no blockers right now 14:07:32 <ykarel> o/ 14:07:36 <amoralej> ok, so once reqchecks are merged we can start branching 14:08:02 <spotz> #cgair ykarel 14:08:09 <spotz> #chair ykarel 14:08:09 <opendevmeet> Current chairs: amoralej apevec[m] jcapitao jpena marios spotz ykarel 14:08:09 <amoralej> #chair ykarel 14:08:09 <opendevmeet> Current chairs: amoralej apevec[m] jcapitao jpena marios spotz ykarel 14:08:22 <jcapitao> yeap, should be branched soon 14:08:38 <amoralej> jcapitao, is the automation to build packages in xena from new releases in openstack/releases enabled? 14:08:57 <jcapitao> yes, we got some already 14:09:03 <amoralej> ok, good 14:09:14 <amoralej> so it's progressing as expected 14:09:24 <amoralej> anything else or we can move to the tripleo on xena topic? 14:09:35 <jcapitao> yes the process is smooth atm 14:09:43 <jcapitao> nothing more on this topic 14:10:26 <amoralej> #topic Plan for TripleO in RDO Xena 14:10:48 <amoralej> #info tripleo project will not create stable/xena branhches 14:11:35 <amoralej> marios, so we can assume that at some point you will provide a list of git tags that should work with stable/xena releases in other projects? 14:11:37 <spotz> marios: Are you representing Tripleo? 14:11:45 <spotz> :) 14:11:49 <marios> spotz: well not officially as i am not ptl :) 14:11:53 <marios> spotz: i was just asked to join ;) 14:12:02 <spotz> I didn't see James on:( 14:12:08 <marios> amoralej: spotz: in general, this is a conversation you need to have with the current PTL regarding the plans 14:12:10 <amoralej> i also aske the ptl to join :) 14:12:31 <marios> but yes the idea is to tag often during the cycle so we can provide the list of 'tested during xena cycle' tags 14:13:20 <apevec[m]> +1 that was my understanding 14:13:31 <apevec[m]> let's put that into minutes FTR 14:13:37 <amoralej> you mean testing xena from master branch in yoga? 14:13:39 <rdogerrit> Lee Yarwood proposed openstack/nova-distgit rpm-master: Requirements sync for Xena https://review.rdoproject.org/r/c/openstack/nova-distgit/+/35482 14:13:40 <rdogerrit> Lee Yarwood proposed openstack/nova-distgit rpm-master: Replace genisoimage dependency with xorriso and mkisofs https://review.rdoproject.org/r/c/openstack/nova-distgit/+/35529 14:13:43 <marios> apevec[m]: sure, it is also on the spec we merged abou that 14:13:45 <amoralej> xena cycle is about to finish :) 14:13:56 <apevec[m]> also, that if something breaks, TripleO will not backport to Xena b/c no branch! 14:14:23 <marios> apevec[m]: also that point, i.e. there is nowhere to backport to for x fixes folks will have to carry them ontop of whatever tag they are using 14:14:39 <amoralej> #link https://specs.openstack.org/openstack/tripleo-specs/specs/xena/tripleo-independent-release.html 14:14:42 <apevec[m]> amoralej: right, so up to GA we're getting tags 14:14:56 <apevec[m]> after that, I would not expect anything 14:14:59 <spotz> But we can safetly upgrade the tags? 14:15:06 <apevec[m]> we'd basically freeze tripleo at GA point 14:15:14 <amoralej> that's my understanding 14:15:21 <amoralej> let me try to summarize 14:15:22 <apevec[m]> spotz: I don't think so, beyond GA 14:15:44 <spotz> apevec[m]: So no way of getting fixes in then 14:15:51 <apevec[m]> b/c after GA TripleO could develop dep on something which is > X 14:16:00 <amoralej> btw, marios is there any mechanism to provide the list of tags other that monitor openstack/releases? 14:16:11 <apevec[m]> spotz: exactly, let's make that clear 14:16:12 <apevec[m]> if TripleO breaks, it will be broken in RDO Xena 14:16:38 <marios> amoralej: not that i know of - i think the idea is that tripleo will start and maintain a list somewhere 14:17:13 <marios> amoralej: but again, better discuss this with current ptl (maybe for the next meeting give them some heads up instead of ping at the start of the meeting ;)) 14:17:16 <apevec[m]> I think what we can commit to, together with TripleO team, is that at RDO Xena GA we will have a working content set 14:17:18 <spotz> Can we do periodic releases to known good tags? 14:17:43 <apevec[m]> beyond GA, no guarantees 14:17:53 <spotz> Wearing my ops hat here. If folks can't get bug fixes, security patches why use it? 14:18:00 <ykarel> yeap periodic tags will not work as those will be for master, as no stable/xena 14:18:10 <apevec[m]> users who want to continue use TripleO, will need to follow master Trunk 14:18:51 <amoralej> #info TripleO will create and designate a range of git tags as compatible with OpenStack Xena at some point after Xena coordinated GA 14:19:02 <amoralej> #info the mechanism to provide the list of tags is TBD 14:19:05 <apevec[m]> spotz: ops using non-TripleO deployment e.g. kolla could continue use RDO Xena with stable/X minor releases 14:19:06 <amoralej> marios, ^ 14:19:09 <amoralej> is that correct? 14:19:16 <marios> amoralej: ack sounds right 14:19:49 <spotz> So kiolla will work, the rpms will work, packstack will work, tripleo no guarantee? 14:20:07 <apevec[m]> right, b/c it was upstream TripleO decision to skip X 14:20:13 <amoralej> #info after those designed tags, there will be no mechanism to backport fixes to xena in TripleO projects and new tags may not be compatible with OpenStack Xena 14:20:29 <apevec[m]> again, guarantee will be at GA point, only 14:20:33 <amoralej> spotz, marios ^ wdyt? 14:20:43 <amoralej> is that clear enough? 14:21:12 <amoralej> actually... i may be more explicit 14:21:14 <apevec[m]> amoralej: maybe add point around GA 14:21:18 <amoralej> #undo 14:21:18 <opendevmeet> Removing item from minutes: #info after those designed tags, there will be no mechanism to backport fixes to xena in TripleO projects and new tags may not be compatible with OpenStack Xena 14:22:20 <amoralej> #info after the designed tags at Xena GA, there will be no mechanism to backport fixes to Xena in TripleO projects and packages will not be updated during the Xena Maintenance period 14:22:39 <jcapitao> +1 14:22:43 <spotz> +1 14:22:45 <apevec[m]> +1 14:22:52 <ykarel> +1 14:23:26 <spotz> And then Yoga would be the same? Or technically we do our RPMs, and packstack and such and no Tripleo for us? 14:23:30 <amoralej> #action spotz et all make this situation clear in Xena release notes 14:24:05 <spotz> We'll know it's clear when I fully have my head wrapped around it:) 14:24:07 <apevec[m]> we'll see for Y 14:24:11 <marios> spotz: well we cant be sure about yoga yet - could be tripleo reconsiders by then. the point with independent is that tripleo is free to actually create the branch when/if they want to 14:24:39 <marios> spotz: in *theory* there would be no yoga with Z the next target but we can't be sure yet 14:24:45 <spotz> marios apevec[m] - But we'll still release RPMs and packstack for Y 14:24:50 <spotz> ? 14:24:51 <marios> spotz: i.e. Z would be created with the current plan 14:25:11 <apevec[m]> yes, RDO continues to package vanilla upstream src in RPMs, that's our definition 14:25:18 <amoralej> spotz, yes, we'll still have the rest of packages as usual 14:25:23 <spotz> OOk Tripleoo comes back into RDO for a Z release. Ok I'm getting it!:) 14:25:47 <apevec[m]> they will be there all the time! 14:25:53 <marios> :) 14:25:54 <apevec[m]> just might get obsolete :) 14:25:57 <amoralej> #action amoralej to send a mail to openstack-discuss to clarify timelines and the mechanism to provide that list 14:25:58 <spotz> Well not updated:) 14:26:04 <amoralej> exactly 14:26:18 <spotz> I do better with full pictures, I'm a visual learner:) 14:26:25 <amoralej> :) 14:26:36 <ykarel> amoralej, wrt xena trunk repos, tripleo packages will be pinned to GA tags in rdoinfo, right? 14:26:49 <amoralej> i'd say so 14:27:08 <ykarel> ok makes sense then 14:27:13 <amoralej> unless tripleo maintainers request other pinning 14:27:49 <amoralej> actually that may be the mechanism to provide the list of tags, a review to rdoinfo 14:27:54 <amoralej> that'd be fine from my side 14:29:30 <amoralej> i think that's it wrt this topic 14:29:36 <amoralej> am i missing something? 14:30:02 <amoralej> just, i think we need to be clear explaining this in release notes or RDO website 14:30:56 <ykarel> +1 14:31:42 <spotz> Both 14:31:51 <jcapitao> yes 14:31:56 <jcapitao> and good point for the review to rdoinfo 14:32:29 <spotz> This might be more confusing then stream at first because stream you can always get though may or may not be bugged. TripleO only if you run master or tags 14:32:52 <spotz> But everything else we offer will be there 14:33:24 <amoralej> for me it's like there will be "maintained" and "unmaintained" releases in terms of TripleO in RDO 14:33:38 <amoralej> it's like two categories of releases, something like that 14:33:55 <spotz> unmaintained makes me think older which is why it took me a bit to get 14:34:20 <amoralej> yeah, i can't find a better word, but probably exist :) 14:34:35 <spotz> We'll work on it:) 14:35:20 <amoralej> yep 14:35:27 <amoralej> next topic 14:35:52 <amoralej> #topic Status of CentOS Stream 9 preparation 14:36:17 <amoralej> #info dependencies bootstrap is almost finished 14:36:33 <amoralej> #link https://cbs.centos.org/koji/builds?start=0&tagID=2392&order=-build_id&inherited=1&latest=1 14:37:04 <amoralej> i think we can prepare the review to add those deps to rdoinfo? 14:37:13 <amoralej> main missing ones are ansible collections 14:37:27 <amoralej> and i think we can take care later as they may need changes in fedora 14:37:31 <amoralej> ykarel, ^ wdyt 14:38:05 <amoralej> so, next steps may be add to rdoinfo and then create the new dlrn builder 14:38:06 <ykarel> amoralej, wdym by later? 14:38:15 <ykarel> prepare rdoinfo for all built deps 14:38:23 <ykarel> and later follow up with pending collections 14:38:29 <amoralej> yes 14:38:35 <amoralej> that's exactly what i meant 14:38:36 <ykarel> ok sounds fine 14:38:50 <amoralej> as this will allow us to do most of the dlrn bootstrap 14:39:01 <ykarel> yes 14:39:13 <amoralej> jpena, ^ fyi 14:39:29 <amoralej> we'll probably need to patch check and gate jobs 14:39:31 <jpena> niec 14:39:33 <amoralej> to cover c9 case 14:39:35 <jpena> *nice 14:40:34 <amoralej> #info next step will be add CS9 tags and builds to rdoinfo 14:41:37 <amoralej> so i think we are in good track for CS9 14:41:49 <amoralej> also some other SIGs are also doing good progress in it 14:42:19 <amoralej> i.e. https://cbs.centos.org/koji/buildinfo?buildID=34580 14:42:56 <amoralej> i think that's mainly it wrt CS9 14:43:03 <amoralej> anything else to share? 14:43:24 <amoralej> apevec[m], wrt network-scripts, should we work in building it as part of RDO deps? 14:43:33 <ykarel> amoralej, so just to confirm, xena will be c8 only or both c8/c9, i am lost 14:43:47 <amoralej> ykarel, will be cs8 first :) 14:44:02 <amoralej> wrt CS9... we'll see 14:44:09 <ykarel> yeap that's what i got, but considering c9 prep going fast so just thought :) 14:44:13 <amoralej> it may be CS9 only in RDO Trunk, i.e. 14:44:36 <amoralej> there are multiple options, i think we don't need to define yet tbh 14:44:49 <ykarel> ack let's take them later 14:44:58 <amoralej> note that even if we have the packages, there may be issues that need upstream changes 14:45:14 <amoralej> i.e. tripleo, ironic, nova, etc... to become ready for CS9 14:45:19 <ykarel> yes right 14:45:28 <amoralej> it's not only about building the packages, but about getting it validated 14:45:48 <ykarel> correct, nothing is gating c9 yet 14:45:53 <amoralej> yep 14:46:15 <amoralej> by providing a RDO Trunk repo for C9 we provide a way to gate puppet or tripleo on cs9 14:46:39 <amoralej> so we can't assume that packages will work as soon as we build them 14:47:54 <amoralej> ykarel, so once we have master branches running on C9 14:48:11 <amoralej> we can decide what to do with xena and wallaby 14:48:26 <ykarel> ack sounds good 14:48:37 <amoralej> ok, so i think that was it wrt CS9 14:48:51 <amoralej> #topic chair for next week 14:48:54 <amoralej> any volunteer? 14:49:22 <ykarel> i will not be around next week meeting time, so can't take 14:49:36 <apevec[m]> sorry got into another call, re. openstack-network-scripts - let's discuss it next week, I'll finish pkg review in the meantime 14:49:51 <jcapitao> amoralej: I can take it 14:50:02 <spotz__> Let me check calendars 14:50:06 <apevec[m]> and re Xena CS9 - yes, TBD, we'll see, for now CS8 is what we decided 14:50:22 <amoralej> #action jcapitao to chair next meeting 14:50:29 <amoralej> #topic open floor 14:50:40 <amoralej> time for anything else you'd like to share 14:50:46 <apevec[m]> oops, sorry for crossing topics! 14:50:58 <spotz___> I can take it 14:51:11 <apevec[m]> spotz___: it's gone ;) 14:51:50 <amoralej> :) 14:52:04 <spotz___> Hehe 14:55:27 <amoralej> if there are no more topics, i'll close the meeting 14:56:22 <amoralej> #endmeeting