14:00:01 <marios> #startmeeting tripleo 14:00:02 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:00:05 <openstack> The meeting name has been set to 'tripleo' 14:00:17 <marios> #topic agenda 14:00:18 <marios> * Review last minutes & action items 14:00:18 <marios> * One off agenda items 14:00:18 <marios> * Bugs & Blueprints 14:00:18 <marios> * Projects releases or stable backports 14:00:20 <marios> * Specs 14:00:22 <marios> * open discussion 14:00:25 <marios> Anyone can use the #link, #action and #info commands, not just the moderatorǃ 14:00:32 <marios> o/ hello tripleo good morning good afternoon good evening! 14:00:36 <beagles> o/ 14:00:38 <tkajinam> o/ 14:00:40 <marios> who is around today? 14:00:40 <weshay|ruck> 0/ 14:00:43 <akahat> o/ 14:00:47 <jbadiapa> o/ 14:00:50 <jpena> o/ 14:00:50 <slagle> hello 14:00:52 <sshnaidm> o/ 14:00:53 <openstackgerrit> Merged openstack/tripleo-common master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/tripleo-common/+/791080 14:00:55 <amoralej> o/ 14:00:56 <openstackgerrit> Merged openstack/tripleo-common master: Ignore non host ports by tag filtering https://review.opendev.org/c/openstack/tripleo-common/+/792260 14:00:57 <jlarriba> o/ 14:01:44 <marios> k lets get going folks can catch up 14:01:49 <marios> #topic review last meeting logs & action items 14:01:55 <fultonj> o/ 14:02:01 <marios> #link http://eavesdrop.openstack.org/meetings/tripleo/2021/tripleo.2021-05-11-14.00.html 14:02:05 <openstackgerrit> 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 <marios> does someone want to discuss anything from the last meeting? 14:03:09 <rlandy> o/ 14:03:17 <fmount> o/ 14:03:20 <marios> sounds like not lets move to the one off items 14:03:21 <ysandeep|ruck> o/ 14:03:26 <marios> #topic one off agenda items 14:03:28 <marios> #link https://etherpad.openstack.org/p/tripleo-meeting-items 14:03:37 <openstackgerrit> 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 <openstackgerrit> 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 <marios> k we have a proposal from the deployment squad around releases and branches 14:04:04 <marios> weshay|ruck: o/ hey do you want to outline the proposal? 14:04:11 <weshay|ruck> hey yes.. thanks 14:04:37 <weshay|ruck> so.. just wanted to get the conversation moving... I think I saw this from other devs originally 14:05:02 <weshay|ruck> Looking to less work that is not VERY important so we can focus more on what is important 14:05:26 <weshay|ruck> so.. the critical item here is changing our release gov.. from trailing to independent... 14:05:30 <weshay|ruck> probably want to start there 14:06:00 <marios> #info proposal Move immediately to an independent release https://releases.openstack.org/reference/release_models.html#independent 14:06:08 <weshay|ruck> 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 <weshay|ruck> any thoughts on that bit? 14:07:12 <slagle> 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 <amoralej> whould be a goal to keep tripleo able to deploy any of the supported openstack major versoins? 14:07:20 <marios> 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 <beagles> it is pretty intriguing - my knee jerk reaction is "yes please" but I'd like to know more 14:07:31 <marios> weshay|ruck: also concern around the timeframe and if we can actually do it in X cycle 14:07:52 <weshay|ruck> aye.. hopefully we're still early enough in the cycle.. 14:08:18 <slagle> 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 <weshay|ruck> so.. I think master tripleo repos would deploy openstack xena, y 14:08:31 <marios> slagle: yeah i worded that wrong 14:08:33 <weshay|ruck> rdo also has the option to tag versions of master.. for rpm deployments 14:08:38 <slagle> i see no reason to hide that 14:08:44 <weshay|ruck> the issue would be patching a specific branch 14:08:54 <marios> 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 <marios> slagle: that would now change ^ 14:09:35 <slagle> well, we're just talking tripleo here. and i see no reason to present a perception that isn't true 14:09:35 <marios> 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 <marios> slagle: but you could use "this list of versions of the tripleo repos" 14:10:08 <marios> slagle: as an alternative 14:10:12 <slagle> correct. i think it's bad for the community as well for the record 14:10:20 <amoralej> from RDO perspective, if tripleo provides a list of tags that are able to deploy Xena, that'd be fine 14:10:21 <jpena> 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 <amoralej> but, what about bugs and fixes? 14:10:47 <tkajinam> if a single version tripleo supports multiple versions of openstack then it would cause burden on puppet modules 14:10:50 <weshay|ruck> support.. is key.. users could still deploy 14:10:50 <amoralej> and CI 14:10:59 <weshay|ruck> it's the patching that would get tricky.. afaict 14:11:13 <slagle> 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 <slagle> also ussuri, also xena 14:11:46 <slagle> we do not want our community using these branches imo 14:11:51 <jpena> weshay|ruck: how would a single tripleo version deploy openstack for xena, y, z? 14:12:16 <weshay|ruck> if things go as planned.. I think we would cut a z branch 14:12:21 <marios> jpena: what is 'single tripleo version' though it would be 'this list of versions fo the various repos' 14:13:10 <weshay|ruck> so tripleo would have.. wallaby, master .. and master branched to z.. 2-3 weeks after openstack releases z 14:13:20 <jpena> 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 <weshay|ruck> so tripleo would release a branch.. but every 3 three releases 14:13:29 <marios> jpena: right 14:13:34 <amoralej> yeah, that's the actual issue 14:13:39 <weshay|ruck> openstack releases that is 14:13:48 <marios> jpena: yeah weshay|ruck said that the patching is a problem i think that is what he referring to 14:14:11 <weshay|ruck> ya.. no patching on xena... just as is.. 14:14:14 <weshay|ruck> or roll w/ master 14:14:19 <slagle> we wouldn't deploy xena, or claim we do 14:14:30 <weshay|ruck> we could also say that 14:14:38 <slagle> no reason to backport anything 14:14:44 <marios> 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 <weshay|ruck> but it gets interesting w/ RDO releasing xena and tripleo not 14:14:55 <slagle> we'd be moving to an independent release model that works for tripleo 14:15:05 <jpena> so are you proposing to release RDO without tripleo packages? 14:15:17 <weshay|ruck> jpena, master tagged... 14:15:29 <weshay|ruck> no patching .. I think 14:15:41 <weshay|ruck> or not.. releasing... tripleo w/ rdo xena 14:15:44 <jpena> that works for RDO Trunk, but not for proper RDO GA releases 14:15:50 <weshay|ruck> and communicate tripleo will release at z 14:15:57 <weshay|ruck> jpena, right 14:16:03 <weshay|ruck> hence why we're here 14:16:08 <slagle> jpena: yes, if rdo wants to continue to release branches that tripleo doesn't support, tripleo wouldn't be there 14:16:22 <slagle> honestly...what is someone to do that deploys rdo ussuri with tripleo or victoria? 14:16:24 <weshay|ruck> 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 <slagle> they are stuck already 14:16:49 <jpena> slagle: with that model, we'd be in the same situation even for wallaby 14:16:54 <marios> 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 <weshay|ruck> sure.. 14:17:20 <marios> i don't think we are going to resolve this here and folks will have chance to express their opinion again 14:17:30 <weshay|ruck> so.. looking at the agenda.. 14:17:33 <amoralej> to be clear, tripleo maintains tripleo packages 14:17:43 <amoralej> it's not rdo maintaining rdo packages 14:17:49 <weshay|ruck> goal is to drop branches that we can .. ASAP.. so what is ASAP 14:17:52 <amoralej> maintaining tripleo packages 14:18:15 <weshay|ruck> the correct way... would be to wait for the dates I've listed in the etherpad 14:18:19 <marios> #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 <weshay|ruck> thanks 14:18:27 <amoralej> responsibility of maintaining tripleo workging in rdo is from tripleo projects 14:18:30 <weshay|ruck> Putting it out there... 14:18:32 <amoralej> including pushing required patches 14:18:47 <amoralej> to keep it working during the cycle 14:18:47 <weshay|ruck> 2. A more agressive proposal and break the release agreement and drop them early 14:19:01 <marios> 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 <weshay|ruck> there are drawbacks to the second part there 14:19:28 <marios> 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 <weshay|ruck> agree 14:19:48 <weshay|ruck> putting it out there for others to weigh in 14:20:00 <marios> weshay|ruck: so really the main thing we need to answer today/first is are we going to keep queens? 14:20:06 <marios> weshay|ruck: or will we start immediately with stein and queens 14:20:31 <marios> the victoria/ussuri follow after this and we can discuss more about the dates on that when the time comes? 14:20:36 <marios> imo weshay|ruck ^ 14:20:37 <weshay|ruck> yes... there was interest from the community to keep Queens alive upstream even though it's EOL 14:20:53 <marios> ramishra: ^^ 14:21:05 <ramishra> 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 <ramishra> so I don't see any issue with an agressive plan to drop branches 14:21:57 <slagle> my take would be to keep train and wallaby and drop all others 14:22:06 <ramishra> slagle: +1 14:22:12 <weshay|ruck> if we could drop branches w/o blow back.. that would be my preference 14:22:17 <sshnaidm> +1 14:22:20 <weshay|ruck> aggressively 14:22:24 <marios> 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 <weshay|ruck> but being careful is also a good idea 14:22:45 <marios> slagle: queens is also requested to keep 14:22:50 <marios> slagle: basically our ffu branches 14:23:09 <slagle> marios: yes, you're right 14:23:20 <weshay|ruck> it would be easier to revive queens if we killed stein, ussuri, victoria 14:23:26 <slagle> basically let's keep the branches we actually support 14:23:30 <weshay|ruck> aye 14:23:50 <weshay|ruck> rdo folks? 14:23:56 <marios> 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 <amoralej> i think there is a mix of support, ds and us 14:24:23 <weshay|ruck> yes.. work there.. but imho d/stream is a better way to handle queens 14:24:26 <amoralej> what means branches that we support? 14:24:41 <slagle> marios: i'm in favor of doing less work, and properly representing what we support. 14:24:47 <weshay|ruck> ++ 14:24:51 <marios> 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 <amoralej> imo for the branches that have been already released as ussuri and victoria, we should commit at least until EM 14:25:31 <weshay|ruck> aye.. that is a valid way to approach it 14:25:31 <ramishra> I would prefer we keep upstream queens too, but ok if we decide to drop it upstream 14:25:34 <slagle> we're not committing them to already, so i don't know why we would commit to anything for u/v 14:25:44 <ramishra> we still patch newton downstream I think 14:25:59 <marios> 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 <weshay|ruck> heh 14:26:10 <tkajinam> I tend to agree with amoralej, considering fact that we see some users in community using u and v... 14:26:15 <amoralej> yes 14:26:19 <slagle> amoralej: it's a problem of perception. imo, no one should install rdo u/v with tripleo. 14:26:25 <amoralej> there is commitment to upstream 14:26:33 <marios> ramishra: last 6 months tripleo-heat-templates: 27 tripleo-common: 9 python-tripleoclient: 1 patches 14:26:36 <amoralej> slagle, that should have been said before releasing those 14:26:39 <amoralej> that's community 14:26:58 <marios> ramishra: and i expect that will diminish more once folks realise we aren't importing any more 14:27:05 <weshay|ruck> this is the potential blow back we'd get 14:27:16 <amoralej> assuming that nobody should use something that the project is releasing doensn't sounds as a way to work with community 14:27:32 <marios> amoralej: yeah i think we have to recognise this cost 14:27:48 <marios> 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 <ramishra> marios: sure, it would less patches as it's old, but we can drop it 14:27:57 <weshay|ruck> 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 <weshay|ruck> my vote would be drop immediately.. stein, ussuri/victoria 14:28:35 <marios> weshay|ruck: i don't think we can do that yet 14:28:43 <marios> weshay|ruck: because we need to give folks some time to react to this proposal 14:28:47 <marios> weshay|ruck: immediate for stein i guess 14:29:05 <weshay|ruck> aye.. immediately being relative.. like we would have to have a period of time... but give notice 14:29:08 <slagle> 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 <marios> 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 <amoralej> imo, in that case the best option would be to not include tripleo packages in rdo for the non supported releases 14:29:27 <amoralej> for future releases 14:29:45 <weshay|ruck> ya.. that seems fair 14:29:51 <amoralej> for past ones... we'll need to handle, is the cost of maintaining u and v so high? 14:30:10 <amoralej> i'd say those two are the main problem ones, as it communicating a change post-release 14:30:11 <weshay|ruck> amoralej, it's not cheap 14:30:13 <marios> 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 <marios> amoralej: including all the infra we need/use for check and the promotion pipelines etc 14:30:51 <weshay|ruck> amoralej, and that wallaby will need to be c8 and c9 14:30:59 <weshay|ruck> we don't have enough resources to do it ALL 14:31:18 <weshay|ruck> if we're smart.. choices will be made 14:31:25 <slagle> and are they really "maintained". should someone really install u* during EM with no way to upgrade? 14:31:30 <slagle> i wouldn't call that maintained 14:31:40 <slagle> i'd call it a trap 14:31:45 <weshay|ruck> heh 14:32:05 <marios> 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 <marios> slagle: good point and this is the kind of thing we need to be prepared with in response to potential criticism 14:32:40 <weshay|ruck> ++ 14:33:14 <marios> 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 <weshay|ruck> that sounds good 14:33:30 <marios> we can followup on the mailing list for the next discussion around these 14:33:31 <amoralej> note that's assuming tripleo has been doing a trap... 14:33:42 <marios> thanks weshay|ruck for bringing it and thanks all for your comments and thoughts so far 14:33:49 <weshay|ruck> thanks marios! 14:34:15 <marios> k a few other community items i will paste here 14:34:22 <marios> #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 <marios> 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 <marios> stable/wallaby is now more stable ;) 14:35:16 <marios> #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 <marios> 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 <marios> obviously train is one of our ffu branches 14:36:04 <marios> i sent that to the list in response to https://review.opendev.org/c/openstack/releases/+/790778/2#message-e981f749aeca64ea971f4e697dd16ba5100ca4a4 14:36:09 <marios> i.e. release team posted that ^ 14:36:22 <marios> any comments or questions on any of those so far please? 14:37:02 <marios> #info http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022442.html * [TripleO] Opting out of global-requirements.txt 14:37:14 <marios> so this is a thread started by slagle about global-requirements 14:37:36 <marios> 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 <marios> for now i believe we will keep the contract 14:37:56 <marios> and so we need to re-add to tripleo-validations and tripleo-ansible 14:38:02 <slagle> yes, i guess so, no one can say for sure how it works 14:38:10 <marios> #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 <marios> the tripleo-ansible one is a bit of a mess there are a few things broken there 14:38:29 <openstackgerrit> 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 <marios> https://review.opendev.org/c/openstack/tripleo-ansible/+/792830/1#message-11c80e7647e369a03b9703a936e5cacbbfab1877 14:38:41 <slagle> and based on what we're trying to add to tripleo-validations, even check-requirements doesn't enforce the contract 14:39:04 <marios> slagle: you mean you found a bug in the job? 14:39:27 <marios> 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 <slagle> maybe. i don't know what it's supposed to do honestly 14:39:56 <slagle> tripleoclient is in test-requirements for tripleo-validations, and the job has no issue with that 14:40:09 <slagle> tripleoclient isn't in g-r 14:40:32 <marios> slagle: i see 14:40:50 <marios> some more links for context here 14:41:06 <marios> #link https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects 14:41:16 <marios> #link https://github.com/openstack/requirements/blob/ce19462764940a4ce99dae4ac2ec7a004c68e9a4/projects.txt#L245-L249 14:41:24 <marios> #link https://github.com/openstack/requirements/blob/f00ad51c3f4de9d956605d81db4ce34fa9a3ba1c/global-requirements.txt#L337 14:41:45 <marios> k any other comments or thoughts on that one for now? 14:42:17 <openstackgerrit> Shnaidman Sagi (Sergey) proposed openstack/tripleo-ansible master: DNM test CI jobs https://review.opendev.org/c/openstack/tripleo-ansible/+/792957 14:42:27 <marios> #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 <marios> slagle: has started wiring up some ci jobs fyi ^^ 14:43:12 <marios> finally, in case you missed it ;) about freenode there is discussion there 14:43:20 <marios> #info http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022539.html Freenode and libera.chat 14:43:29 <marios> it isn't clear what we/openstack is going to do yet 14:43:40 <marios> anyone want to discuss that here? 14:44:05 <marios> i don't know if we want to go ahead and move ourselves anyway, if folks have strong opinion about that? 14:45:01 <marios> i would rather wait and hope we achieve some consensus across openstack 14:45:01 <marios> k any comments otherwise we can move on 14:45:18 <openstackgerrit> 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 <slagle> +1 to wait 14:45:29 <marios> 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 <marios> thanks slagle 14:45:40 <marios> #topic Bugs and blueprints 14:45:40 <marios> #link https://bugs.launchpad.net/tripleo/ 14:45:40 <marios> #link https://storyboard.openstack.org/#!/project/openstack/tripleo-ansible 14:45:40 <marios> #link https://launchpad.net/tripleo/+milestone/xena-1 14:45:40 <marios> #link https://launchpad.net/tripleo/xena 14:45:42 <marios> #link https://launchpad.net/tripleo/wallaby 14:45:48 <marios> any bug related business please? 14:46:28 <marios> 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 <weshay|ruck> just that.. the centos mirrors upstream were all messed up yesterday.. seems to be recovering.. tread lightly today 14:46:46 <marios> thank you weshay|ruck 14:47:04 <openstackgerrit> 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 <marios> k moving on 14:47:11 <marios> #topic Project releases or stable backports 14:47:13 <marios> #info tripleo wallaby repos https://releases.openstack.org/teams/tripleo.html#wallaby 14:47:31 <marios> any release business please? i mentioned the recent releases already in the community items above 14:47:47 <marios> any requests for particular branch? otherwise i think it is time for another round of 'release all the branches' 14:48:04 <marios> (some time real soon now) 14:48:06 <marios> ;) 14:48:11 <marios> moving on ... 14:48:19 <marios> #topic specs 14:48:19 <marios> #info https://review.opendev.org/q/project:openstack/tripleo-specs 14:48:22 <marios> #info https://opendev.org/openstack/tripleo-specs/src/branch/master/specs/xena 14:48:23 <openstackgerrit> 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 <marios> i am aware of at least 3 specs we are gonna try and merge 14:48:45 <marios> https://review.opendev.org/c/openstack/tripleo-specs/+/787535 14:48:53 <marios> https://review.opendev.org/c/openstack/tripleo-specs/+/788850 14:48:59 <marios> https://review.opendev.org/c/openstack/tripleo-specs/+/772442 14:49:19 <marios> these were all discussed at PTG please help to review and merge those soon ^^ 14:49:28 <marios> any comments/questions around specs? 14:50:02 <marios> ok and finally... 14:50:06 <marios> #topic open discussion 14:50:07 <marios> Anything else that folks want to bring up to the meeting? 14:50:51 <openstackgerrit> Shnaidman Sagi (Sergey) proposed openstack/tripleo-ansible master: WIP use podman collection https://review.opendev.org/c/openstack/tripleo-ansible/+/790502 14:50:51 <marios> 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 <marios> #info next meeting in 2 weeks Tuesday 08 June 1400 UTC 14:51:51 <marios> so if there is nothing else then lets close 14:52:05 <marios> thanks everyone for participating today o/ have a great day 14:52:16 <marios> #endmeeting