[kolla] Yoga PTG summary

Michał Nasiadka mnasiadka at gmail.com
Thu Oct 28 13:32:09 UTC 2021


Hi everyone,

Thank you all who participated in the PTG discussions and shared their thoughts and opinions.

Here is the summary of the topics we have discussed:

# General

## We agreed to stop using Launchpad’s Blueprints functionality (which was inconsistently used by us).

## We’ve discussed recently proposed services to Kolla:
Adjutant has a complicated status now (vacant PTL seat and looking for contributors)
Skyline
Venus

We agreed that a project can be added to Kolla/Kolla-Ansible once it fulfills following the criteria of being in OpenStack governance for 1 cycle and having 1 release.
An exception to this criteria is when the patch content is in good quality and there are core reviewers interested in making this functionality merged (but still the project needs to be in OpenStack governance).

## We also discussed adding OSISM collection of Grafana dashboards and Prometheus Alertmgr rules in order to improve the “default deployment” experience for Kolla-Ansible users.

## There was a decision taken to finally retire kolla-cli (since it has been deprecated long time ago).

# Kolla

## We have discussed deprecating and dropping of binary type of Kolla images:
Pros:
* less CI load, less maintenance burden (for a limited Kolla team), users would be running more tested images (since Kolla/Kolla-Ansible CI runs source images CI jobs as voting)
Cons:
* User survey showed that a considerable amount of users is using them - unclear if because that’s a default - or they have chosen to do so.
* Overriding package versions in source variant can be more troublesome than it is in binary

Action plan:
* Improve documentation for source images, especially focusing on its advantages and what might change for current users of binary (when they make the transition)
* Mark binary images as deprecated in Yoga cycle (add a note about deprecation in kolla-build CLI output)
* Improve override options for source images (upper-constraints, etc)

## The next discussion item was to use a common base (single Linux distribution) for Kolla images
Action plan (to make it possible):
* Fix Bifrost and OVN builds for Debian (which are broken now)
* Create CI jobs for mixed host-os/in-container-image-os (including upgrade jobs)
* Deprecate binary images after those two actions are done
* Provide a decent plan with justification and operator feedback in https://etherpad.opendev.org/p/kolla-only-on-debian <https://etherpad.opendev.org/p/kolla-only-on-debian>
* Deprecate CentOS only images (like qdrouterd)

At the same time we agreed on not pursuing CentOS Stream 9 or Ubuntu 22.04 LTS image builds, when those will show up/be required.

## Migration from ElasticSearch to AWS OpenSearch (Elasticsearch fork after ES changed license)
Action items:
* Deprecate Elasticsearch in Yoga
* Build OpenSearch in Yoga

# Kolla-Ansible

## Podman support
We agreed to implement it with as minimum Ansible playbooks/roles changes as possible (mainly rework kolla_docker.py)
Action plan:
* Reduce scope of existing patch to deploy a single service (e.g. MariaDB)
* Write up a rough implementation plan in https://etherpad.opendev.org/p/kolla-docker-systemd-podman <https://etherpad.opendev.org/p/kolla-docker-systemd-podman>
* Add systemd units support for existing Docker implementation
* Add podman installation in Kolla-Ansible’s baremetal role
* Add podman support upon systemd support for Docker

## Change default deployment to use ML2/OVN (instead of ML2/OVS)
We agreed on the criteria to do so:
* Debian OVN packages in Yoga
* Working and reliable migration path
* A way to prevent accidental migration to OVN for existing deployments

And until that is resolved - we’re not going to pursue that decision.

## Keystone system scope continued
Action plan:
* Proposed to split into 3 parts
** use system scope for keystone admin user (done in Xena)
** assign admin role to service users with system scope
** provide flags to enable scope enforcement and new defaults

## Let’s Encrypt
Resume efforts to implement it (since we upgraded to HaProxy 2.2 which enables seamless TLS key/cert replacement)

## More HA settings by default
Action plan:
* Add a docs HA page that describes typical Kolla-Ansible deployment (haproxy, galera cluster, etc) with references to other projects HA configurations (e.g. neutron, octavia)

## Rocky Linux Host OS support
Proposal: Replace CentOS Stream support to Rocky Linux in the longer run
Action plan:
* Add support for Rocky Linux as Host OS (no Kolla container images)

# Kayobe

## Multiple environments part 3
Proposed improvements:
* merge OpenStack custom configs
* merge Kolla Ansible group_vars
* dependencies between environments
* CI testing

## Support RAID with Bifrost via cleaning steps and deploy steps
Action plan:
* Add support to baremetal_node_action Ansible module for manual cleaning and passing deploy steps
* Option: Enable automated cleaning to erase metadata
* Add support for using this functionality to Bifrost
* Add passing of deploy_steps and cleaning_steps from Kayobe to Bifrost

## Create collection(s) for external Ansible roles that Kayobe depends on (those from StackHPC namespace)
* Group Kayobe external roles to collections (the whole ,,ecosystem’’ of stackhpc.* roles)
* Encourage Kayobe role users to move to collections
* Add/improve CI testing for the collection

For details please check the Kolla Yoga PTG etherpad: https://etherpad.opendev.org/p/kolla-yoga-ptg <https://etherpad.opendev.org/p/kolla-yoga-ptg>

And see you on the weekly meetings: https://meetings.opendev.org/#Kolla_Team_Meeting <https://meetings.opendev.org/#Kolla_Team_Meeting>

Best Regards,

Michal Nasiadka

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211028/d80a94e3/attachment.htm>


More information about the openstack-discuss mailing list