[tripleo] move os-refresh-config, os-collect-config, tripleo-ipsec to 'release-management': none
marios at redhat.com
Tue Jan 12 12:43:30 UTC 2021
On Tue, Jan 12, 2021 at 12:07 PM Marios Andreou <marios at redhat.com> wrote:
> On Mon, Jan 11, 2021 at 5:07 PM Herve Beraud <hberaud at redhat.com> wrote:
>> Le lun. 11 janv. 2021 à 15:27, Alex Schultz <aschultz at redhat.com> a
>> écrit :
>>> On Mon, Jan 11, 2021 at 4:59 AM Marios Andreou <marios at redhat.com>
>>> > Hi TripleO,
>>> > you may have seen the thread started by Herve at  around the
>>> deadline for making a victoria release for os-refresh-config,
>>> os-collect-config and tripleo-ipsec.
>>> > This message is to ask if anyone is still using these? In particular
>>> would anyone mind if we stopped making tagged releases, as discussed at
>>> . Would someone mind if there was no stable/victoria branch for these
>>> > For the os-refresh/collect-config I suspect the answer is NO - at
>>> least, we aren't using these any more in the 'normal' tripleo deployment
>>> for a good while now, since we switched to config download by default. We
>>> haven't even created an ussuri branch for these  and no one has shouted
>>> about that (or at least not loud enough I haven't heard anything).
>>> Maybe switch to independent? That being said as James points out they
>>> are still used by Heat so maybe the ownership should be moved.
>> I agree, moving them to the independent model could be a solution, in
>> this case the patch could be adapted to reflect that choice and we could
>> ignore these repos from victoria deadline point of view.
>> Concerning the "ownership" side of the question this is more an internal
>> discussion between teams and eventually the TC, I don't think that that
>> will impact us from a release management POV.
> ack yes this makes sense thanks James, Alex, Herve and Rabi for your
> First I'll refactor
> https://review.opendev.org/c/openstack/releases/+/769915 to instead move
> them to independent (and i'll also include os-apply-config). Then I'll
> reach out to Heat PTL to see what they think about the transfer of
> thanks all
me again ;)
my apologies but I've spent some time staring at this and have changed my
mind. IMO it is best if we go ahead and create the victoria bits for these
right now whilst also moving forward on the proposed governance change.
To be clear, I think we should merge  as is to create stable/victoria in
time for the deadline. We already have a stable/victoria for
os-apply-config and so let's be consistent and create it for
os-refresh-config and os-collect-config too.
I reached out to Heat with  and posted  to illustrate the proposal of
moving the governance for these under Heat. If they want them then they can
decide about moving to independent or not.
Otherwise I will followup next week with a move to independent.
>>> > For tripleo-ipsec it *looks* like we're still using it in the sense
>>> that we carry the template and pass the parameters in
>>> tripleo-heat-templates . However we aren't running that in any CI job as
>>> far as I can see, and we haven't created any branches there since Rocky. So
>>> is anyone using tripleo-ipsec?
>>> I think tripleo-ipsec is no longer needed as we now have proper
>>> tls-everywhere support. We might want to revisit this and
>>> deprecate/remove it.
>>> > Depending on the answers here and as discussed at  I will move to
>>> make these as unreleased (release-management: none in openstack/governance
>>> reference/projects.yaml) and remove the release file altogether.
>>> > For now however and given the deadline of this week for a victoria
>>> release I am proposing that we move forward with  and cut the victoria
>>> branch for these.
>>> > thanks for reading and please speak up if any of the above are
>>> important to you!
>>> > thanks, marios
>>> > 
>>> > 
>>> >  https://pastebin.com/raw/KJ0JxKPx
>>> > 
>> Hervé Beraud
>> Senior Software Engineer at Red Hat
>> irc: hberaud
>> -----BEGIN PGP SIGNATURE-----
>> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the openstack-discuss