14:00:01 #startmeeting tripleo 14:00:02 Meeting started Tue May 25 14:00:01 2021 UTC and is due to finish in 60 minutes. The chair is marios. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:03 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 The meeting name has been set to 'tripleo' 14:00:17 #topic agenda 14:00:18 * Review last minutes & action items 14:00:18 * One off agenda items 14:00:18 * Bugs & Blueprints 14:00:18 * Projects releases or stable backports 14:00:20 * Specs 14:00:22 * open discussion 14:00:25 Anyone can use the #link, #action and #info commands, not just the moderatorǃ 14:00:32 o/ hello tripleo good morning good afternoon good evening! 14:00:36 o/ 14:00:38 o/ 14:00:40 who is around today? 14:00:40 0/ 14:00:43 o/ 14:00:47 o/ 14:00:50 o/ 14:00:50 hello 14:00:52 o/ 14:00:53 Merged openstack/tripleo-common master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/tripleo-common/+/791080 14:00:55 o/ 14:00:56 Merged openstack/tripleo-common master: Ignore non host ports by tag filtering https://review.opendev.org/c/openstack/tripleo-common/+/792260 14:00:57 o/ 14:01:44 k lets get going folks can catch up 14:01:49 #topic review last meeting logs & action items 14:01:55 o/ 14:02:01 #link http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-05-11-14.00.html 14:02:05 Juan Larriba proposed openstack/tripleo-ansible master: Remove become: true from the role https://review.opendev.org/c/openstack/tripleo-ansible/+/792978 14:02:19 does someone want to discuss anything from the last meeting? 14:03:09 o/ 14:03:17 o/ 14:03:20 sounds like not lets move to the one off items 14:03:21 o/ 14:03:26 #topic one off agenda items 14:03:28 #link https://etherpad.openstack.org/p/tripleo-meeting-items 14:03:37 Brent Eagles proposed openstack/tripleo-heat-templates master: Move designate from experimental https://review.opendev.org/c/openstack/tripleo-heat-templates/+/792467 14:03:38 Brent Eagles proposed openstack/tripleo-heat-templates master: Add support for setting min TTL limit in designate https://review.opendev.org/c/openstack/tripleo-heat-templates/+/792478 14:03:52 k we have a proposal from the deployment squad around releases and branches 14:04:04 weshay|ruck: o/ hey do you want to outline the proposal? 14:04:11 hey yes.. thanks 14:04:37 so.. just wanted to get the conversation moving... I think I saw this from other devs originally 14:05:02 Looking to less work that is not VERY important so we can focus more on what is important 14:05:26 so.. the critical item here is changing our release gov.. from trailing to independent... 14:05:30 probably want to start there 14:06:00 #info proposal Move immediately to an independent release https://releases.openstack.org/reference/release_models.html#independent 14:06:08 this would enable us to not create branches that we may not want/need in the future.. and stop the bleeding w/ the effort required to backport 14:06:29 any thoughts on that bit? 14:07:12 i like the idea, but would like to see some more detail. what would the plan be? to not branch for xena? 14:07:16 whould be a goal to keep tripleo able to deploy any of the supported openstack major versoins? 14:07:20 weshay|ruck: so i've expressed my concern about opening ourselves to criticism ... 'red hat doesn't support openstack X' if we decide not to branch X for example. we should at least anticipate this and consider how the community might use it (e.g. tags) 14:07:25 it is pretty intriguing - my knee jerk reaction is "yes please" but I'd like to know more 14:07:31 weshay|ruck: also concern around the timeframe and if we can actually do it in X cycle 14:07:52 aye.. hopefully we're still early enough in the cycle.. 14:08:18 marios: i don't want to lend validity to that criticism, but it would be true. rh does not plan to support X 14:08:20 so.. I think master tripleo repos would deploy openstack xena, y 14:08:31 slagle: yeah i worded that wrong 14:08:33 rdo also has the option to tag versions of master.. for rpm deployments 14:08:38 i see no reason to hide that 14:08:44 the issue would be patching a specific branch 14:08:54 slagle: more like, red hat doesn't care about X (which is a true statemtent for our product, but so far at least we would produce the same branches as the rest of the upstream community 14:09:07 slagle: that would now change ^ 14:09:35 well, we're just talking tripleo here. and i see no reason to present a perception that isn't true 14:09:35 slagle: so you want to consume openstack nova stable/xena and neutron and all the other things but you won't be able to deploy it with stable/xena tripleo 14:10:04 slagle: but you could use "this list of versions of the tripleo repos" 14:10:08 slagle: as an alternative 14:10:12 correct. i think it's bad for the community as well for the record 14:10:20 from RDO perspective, if tripleo provides a list of tags that are able to deploy Xena, that'd be fine 14:10:21 from a community point of view, my reaction to this would be "just make it downstream-only if they don't want to support all releases" 14:10:41 but, what about bugs and fixes? 14:10:47 if a single version tripleo supports multiple versions of openstack then it would cause burden on puppet modules 14:10:50 support.. is key.. users could still deploy 14:10:50 and CI 14:10:59 it's the patching that would get tricky.. afaict 14:11:13 e.g., no one is even working on a v->w upgrade, we should not have the perception that we support victoria 14:11:22 also ussuri, also xena 14:11:46 we do not want our community using these branches imo 14:11:51 weshay|ruck: how would a single tripleo version deploy openstack for xena, y, z? 14:12:16 if things go as planned.. I think we would cut a z branch 14:12:21 jpena: what is 'single tripleo version' though it would be 'this list of versions fo the various repos' 14:13:10 so tripleo would have.. wallaby, master .. and master branched to z.. 2-3 weeks after openstack releases z 14:13:20 marios: so let's say tag XYZ can be used to deploy Xena. And post-release we find out that we need some patches on top of that tag. How do we do that, if there's no branch and tag XYZ+1 has moved on to support the next release? 14:13:28 so tripleo would release a branch.. but every 3 three releases 14:13:29 jpena: right 14:13:34 yeah, that's the actual issue 14:13:39 openstack releases that is 14:13:48 jpena: yeah weshay|ruck said that the patching is a problem i think that is what he referring to 14:14:11 ya.. no patching on xena... just as is.. 14:14:14 or roll w/ master 14:14:19 we wouldn't deploy xena, or claim we do 14:14:30 we could also say that 14:14:38 no reason to backport anything 14:14:44 slagle: the idea is you might try to deploy xena with tripleo, but you absolutely cant fix something in xena tripleo cos there is no such thing 14:14:47 but it gets interesting w/ RDO releasing xena and tripleo not 14:14:55 we'd be moving to an independent release model that works for tripleo 14:15:05 so are you proposing to release RDO without tripleo packages? 14:15:17 jpena, master tagged... 14:15:29 no patching .. I think 14:15:41 or not.. releasing... tripleo w/ rdo xena 14:15:44 that works for RDO Trunk, but not for proper RDO GA releases 14:15:50 and communicate tripleo will release at z 14:15:57 jpena, right 14:16:03 hence why we're here 14:16:08 jpena: yes, if rdo wants to continue to release branches that tripleo doesn't support, tripleo wouldn't be there 14:16:22 honestly...what is someone to do that deploys rdo ussuri with tripleo or victoria? 14:16:24 I don't think TripleO HAS to be part of every rdo release.. or rdo could follow and not release xena, y 14:16:29 they are stuck already 14:16:49 slagle: with that model, we'd be in the same situation even for wallaby 14:16:54 ok i think we should try and let folks digest this proposal as a first step and we need to followup on the mailing list and then probabaly again here in 2 weeks... weshay|ruck do you want to move onto the second part about deleting branches (which is potentially less controversial) 14:17:13 sure.. 14:17:20 i don't think we are going to resolve this here and folks will have chance to express their opinion again 14:17:30 so.. looking at the agenda.. 14:17:33 to be clear, tripleo maintains tripleo packages 14:17:43 it's not rdo maintaining rdo packages 14:17:49 goal is to drop branches that we can .. ASAP.. so what is ASAP 14:17:52 maintaining tripleo packages 14:18:15 the correct way... would be to wait for the dates I've listed in the etherpad 14:18:19 #info Drop Queens, Stein this cycle https://releases.openstack.org/index.html Drop Ussuri 2021-11-12 Drop Victoria 2022-04-18 14:18:24 thanks 14:18:27 responsibility of maintaining tripleo workging in rdo is from tripleo projects 14:18:30 Putting it out there... 14:18:32 including pushing required patches 14:18:47 to keep it working during the cycle 14:18:47 2. A more agressive proposal and break the release agreement and drop them early 14:19:01 weshay|ruck: the proposal as-is on the etherpad is OK wrt upstream dates as they align with the Extended maintenance (at which point we are OK to move it EOL) 14:19:03 there are drawbacks to the second part there 14:19:28 weshay|ruck: if we want to make it more aggressive, then it is more controversial and we may well get pushback from release team 14:19:35 agree 14:19:48 putting it out there for others to weigh in 14:20:00 weshay|ruck: so really the main thing we need to answer today/first is are we going to keep queens? 14:20:06 weshay|ruck: or will we start immediately with stein and queens 14:20:31 the victoria/ussuri follow after this and we can discuss more about the dates on that when the time comes? 14:20:36 imo weshay|ruck ^ 14:20:37 yes... there was interest from the community to keep Queens alive upstream even though it's EOL 14:20:53 ramishra: ^^ 14:21:05 weshay|ruck: what do we mean by the release agreement? why there would be push back from the realease team? We don't follow stable policy as I mentioned in the ML 14:21:27 so I don't see any issue with an agressive plan to drop branches 14:21:57 my take would be to keep train and wallaby and drop all others 14:22:06 slagle: +1 14:22:12 if we could drop branches w/o blow back.. that would be my preference 14:22:17 +1 14:22:20 aggressively 14:22:24 ramishra: ok, then we have 2 things to discuss here... fist is about queens keeping/not, second is if we are going to remove victoria/ussuri earlier than upstream extended maintenance and when 14:22:31 but being careful is also a good idea 14:22:45 slagle: queens is also requested to keep 14:22:50 slagle: basically our ffu branches 14:23:09 marios: yes, you're right 14:23:20 it would be easier to revive queens if we killed stein, ussuri, victoria 14:23:26 basically let's keep the branches we actually support 14:23:30 aye 14:23:50 rdo folks? 14:23:56 weshay|ruck: slagle: for queens, the alternative proposal is that we go ahead remove it upstream and supplement with d/stream check jobs 14:24:13 i think there is a mix of support, ds and us 14:24:23 yes.. work there.. but imho d/stream is a better way to handle queens 14:24:26 what means branches that we support? 14:24:41 marios: i'm in favor of doing less work, and properly representing what we support. 14:24:47 ++ 14:24:51 ramishra: would you be happy with that? i mean d/stream ? i.e. i am still not clear on what folks feel about keeping queens or not 14:25:05 imo for the branches that have been already released as ussuri and victoria, we should commit at least until EM 14:25:31 aye.. that is a valid way to approach it 14:25:31 I would prefer we keep upstream queens too, but ok if we decide to drop it upstream 14:25:34 we're not committing them to already, so i don't know why we would commit to anything for u/v 14:25:44 we still patch newton downstream I think 14:25:59 ramishra: i did a brief survey and it doesn't look that queens is that busy upstream https://gist.github.com/marios/b3155fe3b1318cc26bfa4bc15c764a26#gistcomment-3752102 14:25:59 heh 14:26:10 I tend to agree with amoralej, considering fact that we see some users in community using u and v... 14:26:15 yes 14:26:19 amoralej: it's a problem of perception. imo, no one should install rdo u/v with tripleo. 14:26:25 there is commitment to upstream 14:26:33 ramishra: last 6 months tripleo-heat-templates: 27 tripleo-common: 9 python-tripleoclient: 1 patches 14:26:36 slagle, that should have been said before releasing those 14:26:39 that's community 14:26:58 ramishra: and i expect that will diminish more once folks realise we aren't importing any more 14:27:05 this is the potential blow back we'd get 14:27:16 assuming that nobody should use something that the project is releasing doensn't sounds as a way to work with community 14:27:32 amoralej: yeah i think we have to recognise this cost 14:27:48 amoralej: its the point i was making earlier, even if we decide to go ahead we need to understand this criticism we can face about this decision 14:27:49 marios: sure, it would less patches as it's old, but we can drop it 14:27:57 and we should try to anticipate, acknoledge that feedback and dropping released branches.. but if I have to weigh the work ahead and the value of old branches 14:28:13 my vote would be drop immediately.. stein, ussuri/victoria 14:28:35 weshay|ruck: i don't think we can do that yet 14:28:43 weshay|ruck: because we need to give folks some time to react to this proposal 14:28:47 weshay|ruck: immediate for stein i guess 14:29:05 aye.. immediately being relative.. like we would have to have a period of time... but give notice 14:29:08 i agree it's unfriendly to the community to drop/discontinue released items. but we should honestly ask if folks are using these things, and if they are, how they plan to upgrade 14:29:13 weshay|ruck: for victoria/ussuri as soon as we decide we are doing this (or rather, wait for someone to tell us that it is really a terrible idea ) 14:29:20 imo, in that case the best option would be to not include tripleo packages in rdo for the non supported releases 14:29:27 for future releases 14:29:45 ya.. that seems fair 14:29:51 for past ones... we'll need to handle, is the cost of maintaining u and v so high? 14:30:10 i'd say those two are the main problem ones, as it communicating a change post-release 14:30:11 amoralej, it's not cheap 14:30:13 amoralej: well the point is it is more than nothing 14:30:40 * weshay|ruck notes developer time spent backporting.. promotion time, fixing bugs.. etc.. 14:30:41 amoralej: including all the infra we need/use for check and the promotion pipelines etc 14:30:51 amoralej, and that wallaby will need to be c8 and c9 14:30:59 we don't have enough resources to do it ALL 14:31:18 if we're smart.. choices will be made 14:31:25 and are they really "maintained". should someone really install u* during EM with no way to upgrade? 14:31:30 i wouldn't call that maintained 14:31:40 i'd call it a trap 14:31:45 heh 14:32:05 k lets try and wrap this up soon for now i think and again we need to followup in the list next for more discussion once folks have a think about it some more 14:32:33 slagle: good point and this is the kind of thing we need to be prepared with in response to potential criticism 14:32:40 ++ 14:33:14 so two main proposals in sumary, 1. move all tripleo repos independent, 2. drop old branches, possibly even u and v before they are extended maintenance 14:33:24 that sounds good 14:33:30 we can followup on the mailing list for the next discussion around these 14:33:31 note that's assuming tripleo has been doing a trap... 14:33:42 thanks weshay|ruck for bringing it and thanks all for your comments and thoughts so far 14:33:49 thanks marios! 14:34:15 k a few other community items i will paste here 14:34:22 #info Releases: https://review.opendev.org/c/openstack/releases/+/790794 * Make release for tripleo independent repos https://review.opendev.org/c/openstack/releases/+/791959 * Make new release for tripleo repos stable/wallaby 14:34:50 so i made a new release for the independent repos and also a new stable/wallaby after we merged all the tripleiclient/tripleo-common bits and CI was happy again ^^^ 14:34:58 stable/wallaby is now more stable ;) 14:35:16 #info http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022428.html * [TripleO] tripleo repos going Extended Maintenance stable/train OK? (not yet IMO) 14:35:38 this is related to the discussion we just had... so proposal is for train to go extended maintenance but i think we want to hold on that as long as we can 14:35:48 obviously train is one of our ffu branches 14:36:04 i sent that to the list in response to https://review.opendev.org/c/openstack/releases/+/790778/2#message-e981f749aeca64ea971f4e697dd16ba5100ca4a4 14:36:09 i.e. release team posted that ^ 14:36:22 any comments or questions on any of those so far please? 14:37:02 #info http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022442.html * [TripleO] Opting out of global-requirements.txt 14:37:14 so this is a thread started by slagle about global-requirements 14:37:36 there were concerns raised about if this would cause build problems (in rdo builds for example) if we aren't getting the checks upstream 14:37:46 for now i believe we will keep the contract 14:37:56 and so we need to re-add to tripleo-validations and tripleo-ansible 14:38:02 yes, i guess so, no one can say for sure how it works 14:38:10 #info for now re-adding tripleo-ansible https://review.opendev.org/c/openstack/tripleo-ansible/+/792830 & tripleo-validations https://review.opendev.org/c/openstack/tripleo-validations/+/792643 14:38:25 the tripleo-ansible one is a bit of a mess there are a few things broken there 14:38:29 Harald Jensås proposed openstack/tripleo-common stable/wallaby: Strip final dot of the fqdn hostname and dnsname https://review.opendev.org/c/openstack/tripleo-common/+/792887 14:38:37 https://review.opendev.org/c/openstack/tripleo-ansible/+/792830/1#message-11c80e7647e369a03b9703a936e5cacbbfab1877 14:38:41 and based on what we're trying to add to tripleo-validations, even check-requirements doesn't enforce the contract 14:39:04 slagle: you mean you found a bug in the job? 14:39:27 slagle: it seems to pick up some valid things in tripleo-ansible (that have been allowed so far because the job was removed there) 14:39:36 maybe. i don't know what it's supposed to do honestly 14:39:56 tripleoclient is in test-requirements for tripleo-validations, and the job has no issue with that 14:40:09 tripleoclient isn't in g-r 14:40:32 slagle: i see 14:40:50 some more links for context here 14:41:06 #link https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects 14:41:16 #link https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7a004c68e9a4/projects.txt#L245-L249 14:41:24 #link https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce34fa9a3ba1c/global-requirements.txt#L337 14:41:45 k any other comments or thoughts on that one for now? 14:42:17 Shnaidman Sagi (Sergey) proposed openstack/tripleo-ansible master: DNM test CI jobs https://review.opendev.org/c/openstack/tripleo-ansible/+/792957 14:42:27 #info http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022585.html * [TripleO] tripleo-ci-centos-8-containers-multinode now using ephemeral Heat for master/wallaby 14:42:34 slagle: has started wiring up some ci jobs fyi ^^ 14:43:12 finally, in case you missed it ;) about freenode there is discussion there 14:43:20 #info http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022539.html Freenode and libera.chat 14:43:29 it isn't clear what we/openstack is going to do yet 14:43:40 anyone want to discuss that here? 14:44:05 i don't know if we want to go ahead and move ourselves anyway, if folks have strong opinion about that? 14:45:01 i would rather wait and hope we achieve some consensus across openstack 14:45:01 k any comments otherwise we can move on 14:45:18 Harald Jensås proposed openstack/tripleo-common stable/wallaby: Ignore non host ports by tag filtering https://review.opendev.org/c/openstack/tripleo-common/+/792888 14:45:23 +1 to wait 14:45:29 k moving on, we are getting late on time so gonna move quickly here please stop me if you want to say something ;) 14:45:32 thanks slagle 14:45:40 #topic Bugs and blueprints 14:45:40 #link https://bugs.launchpad.net/tripleo/ 14:45:40 #link https://storyboard.openstack.org/#!/project/openstack/tripleo-ansible 14:45:40 #link https://launchpad.net/tripleo/+milestone/xena-1 14:45:40 #link https://launchpad.net/tripleo/xena 14:45:42 #link https://launchpad.net/tripleo/wallaby 14:45:48 any bug related business please? 14:46:28 usual reminder please triage your xena-1 things ;) we moved all the wallaby-rc1 things to xena-1 at least some of those have outdated info, e.g. fixed but still marked triaged 14:46:35 just that.. the centos mirrors upstream were all messed up yesterday.. seems to be recovering.. tread lightly today 14:46:46 thank you weshay|ruck 14:47:04 Shnaidman Sagi (Sergey) proposed openstack/tripleo-ansible master: Fix failures because of Jinja version limit https://review.opendev.org/c/openstack/tripleo-ansible/+/792988 14:47:10 k moving on 14:47:11 #topic Project releases or stable backports 14:47:13 #info tripleo wallaby repos https://releases.openstack.org/teams/tripleo.html#wallaby 14:47:31 any release business please? i mentioned the recent releases already in the community items above 14:47:47 any requests for particular branch? otherwise i think it is time for another round of 'release all the branches' 14:48:04 (some time real soon now) 14:48:06 ;) 14:48:11 moving on ... 14:48:19 #topic specs 14:48:19 #info https://review.opendev.org/q/project:openstack/tripleo-specs 14:48:22 #info https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/xena 14:48:23 Jiri Podivin proposed openstack/python-tripleoclient master: Changing the constant to reflect new VF behavior. https://review.opendev.org/c/openstack/python-tripleoclient/+/792990 14:48:39 i am aware of at least 3 specs we are gonna try and merge 14:48:45 https://review.opendev.org/c/openstack/tripleo-specs/+/787535 14:48:53 https://review.opendev.org/c/openstack/tripleo-specs/+/788850 14:48:59 https://review.opendev.org/c/openstack/tripleo-specs/+/772442 14:49:19 these were all discussed at PTG please help to review and merge those soon ^^ 14:49:28 any comments/questions around specs? 14:50:02 ok and finally... 14:50:06 #topic open discussion 14:50:07 Anything else that folks want to bring up to the meeting? 14:50:51 Shnaidman Sagi (Sergey) proposed openstack/tripleo-ansible master: WIP use podman collection https://review.opendev.org/c/openstack/tripleo-ansible/+/790502 14:50:51 any volunteers to run the next tripleo irc meeting? maybe you always wanted to do it ;) let me know if you want to try it 14:51:31 #info next meeting in 2 weeks Tuesday 08 June 1400 UTC 14:51:51 so if there is nothing else then lets close 14:52:05 thanks everyone for participating today o/ have a great day 14:52:16 #endmeeting