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