On Tue, Feb 21, 2023 at 8:57 PM Steve Baker <sbaker(a)redhat.com> wrote:
I see os-collect-config/os-apply-config/os-refresh-config are in the retired list.
Package openstack-heat-agents are coupled with these 3 packages, as one of the agent
options, and for bootstrap on a provisioned host. There may be RDO community usage of
these packages independent of TripleO.
Can these be moved to non-tripleo openstack projects, along with openstack-heat-agents?
Sure, then I think it makes sense to add
os-collect-config/os-apply-config/os-refresh-config to common
components together with openstack-heat-agents. I've move them in the
etherpad.
Thanks
On 22/02/23 04:30, Alfredo Moralejo Alonso wrote:
Hi,
As communicated in an openstack-discuss thread [1] the TripleO team is
willing to deprecate master and Zed branches of TripleO repos. While
the process for Zed is still under discussion with TC [2], there will
not be new releases for Antelope and following releases. In the last
meeting of RDO we discussed how to manage this change in RDO [3], and
this is our proposal.
TripleO packages in RDO releases
- We will maintain TripleO packages in RDO in RDO-Trunk master until
the content of the master branch is removed. According to the info
provided by TripleO CI team, jobs for the master branch will keep
running for some time.
- Zed release is under discussion. We will follow the same approach as
for the master branch and remove the packages from RDO Trunk once the
branches are removed. We'll keep them if they stay in Extented
Maintenance.
- For Antelope release, which is under preparation for GA, we will not
include TripleO packages in CloudSIG official repos. We will also
remove them rpm RDO Trunk once we have confirmation from the TripleO
CI team that they don't need it anymore (or with master branch removal
at latest)
Currently, TripleO component includes 102 packages but not all of them
are TripleO specific:
- Non-tripleo puppet modules: we will maintain those in a new
component "puppet".
- Some packages for OpenStack services Heat, Zaqar and Mistral. We
need to look for new components for those, would common be a good fit?
- Non-TripleO ansible roles: are those used out of TripleO? I guess
not, but I'm willing to get feedback from RDO users about what may be
useful so that we can move it to another component
- TripleO packages. To be retired. If any package can be useful for
any other deployment tool, those may be moved to the suitable
component too.
You can find the entire list of packages in
https://review.rdoproject.org/etherpad/p/post-tripleo-proposal , feel
free to check it and provide any feedback there.
RDO definition-of-done
Since last releases, the release criteria for new releases of RDO has
been based on puppet-openstack-integration, packstack (which also
relies on OpenStack Puppet modules) and TripleO jobs results.
This change forces us to adapt the RDO definition of done. In Antelope
the release criteria will be only based on the
puppet-openstack-integration and packstack jobs (8 jobs) Correct for
Antelope. Going forward, we will reevaluate this in future releases.
We will continue refining this plan the next few weeks, please let us
know any doubt or suggestion that you may have on this thread, in #rdo
or in the weekly meetings (wed. 14:00 UTC in #rdo).
Best regards,
Alfredo
[1]
https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032...
[2]
https://lists.openstack.org/pipermail/openstack-discuss/2023-February/032...
[3]
https://meetings.opendev.org/meetings/rdo_meeting___2023_02_15/2023/rdo_m...
_______________________________________________
dev mailing list -- dev(a)lists.rdoproject.org
To unsubscribe send an email to dev-leave(a)lists.rdoproject.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
To unsubscribe: %(_internal_name)s-unsubscribe@%(host_name)s
_______________________________________________
dev mailing list -- dev(a)lists.rdoproject.org
To unsubscribe send an email to dev-leave(a)lists.rdoproject.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
To unsubscribe: %(_internal_name)s-unsubscribe@%(host_name)s