Adventures of a Small Time OpenStack Sysadmin relate the experience of converting a small VMware cluster into two small OpenStack clusters, and the adventures and friends I made along the way.
Adventures of a Small Time OpenStack Sysadmin Chapter 051 - Why I'm not using almost all the *aaS OpenStack offerings.
Intro
The only *aaS offering I'm currently using from OpenStack is Designate. Designate works perfectly, installs easily, and is reliable in operation. As for the other *aaS offerings, at least as of midsummer 2022 in the Yoga release of Kolla-Ansible... well...
Solum
https://docs.openstack.org/solum/yoga/
There seems to be no Project Deployment Configuration Reference document for Solum.
Solum is equivalent to "Cap Rover" or "Dokku" as an OpenStack integrated service instead of a Zun container orchestrated by OpenStack Heat. If I needed that functionality I'd install the Docker containers or just go commercial and install on Heroku (although Heroku is incredibly expensive to use...)
AFAIK Solum works, although I have not tried it, so ...
Magnum
The idea of a service providing Docker Swarms and K8S clusters is compelling, and I'd be excited to use it, if it were not a dead project.
https://docs.openstack.org/magnum/yoga/
Kolla-Ansible Deployment Configuration Reference for Magnum
https://docs.openstack.org/kolla-ansible/yoga/reference/containers/magnum-guide.html
Some config examples I experimented unsuccessfully with:
https://docs.openstack.org/magnum/yoga/configuration/sample-config.html
The wiki explains the very limited compatibility list for each different Magnum version.
https://wiki.openstack.org/wiki/Magnum
Magnum seems dead for a couple years and a couple Kolla-Ansible project releases:
http://lists.openstack.org/pipermail/openstack-discuss/2021-August/024273.html
General discussion seems to indicate that despite documentation advertising the contraty, Magnum does not seem capable of running Docker Swarm anymore, which is too bad.
The good news is I can replace Magnum by a medium sized Heat Template and some Ansible Playbooks faster than I can fix the Magnum project.
Murano
A GUI application catalog. Cool, would enjoy trying that. Luckily, I don't really need it, because it's a dead project.
https://docs.openstack.org/murano/yoga/
There seems to be no Kolla-Ansible Project Deployment Configuration Reference document for Murano.
The Murano project appears to be dead. There's a bug reported 17 months ago from back on Victoria release that I unfortunately easily reproduced locally on Yoga. This makes the project uninstallable, no one seems to care, project seems dead. Bye!
https://bugs.launchpad.net/kolla-ansible/+bug/1916370
https://docs.openstack.org/manila/yoga/
Kolla-Ansible Project Deployment Configuration Reference for Manila
https://docs.openstack.org/kolla-ansible/yoga/reference/storage/manila-guide.html
The personal problem I have with Manila is it creates a software NAS using Cinder. But I have excellent hardware NAS infrastructure existing, and I have no good Cinder based backup solution, and if I needed a software NAS installed in an instance I'd just install TrueNAS into an instance and be done with it. It solves the opposite of all my storage problems. I assume it is very useful to some people, and I'm happy for those people that it exists. I have an excellent NFS hardware NAS infrastructure with backups and everything, and I could run Manila on top of it to provide CIFS, but I'd probably find it easier to install, operate, and troubleshoot a Samba instance.
AFAIK, based on gossip from people using it, it reportedly works well.
Sahara
This project seems to be like Manila but for cloudy big data servers instead.
https://docs.openstack.org/sahara/yoga/
There does not seem to be a Kolla-Ansible Project Deployment Configuration Reference document for Sahara.
I'm not even going to try Sahara. There are no errors when installing but the docs have not been updated since Newton (I'm on Yoga) and I don't actually have a use case for anything it can do, and if I did, I'd install a fresh brand new up to date Docker container instead of something from back when the Newton release was new... I'm not saying its a dead project, but when the docs are that old...
Senlin
https://docs.openstack.org/senlin/yoga/
There seems to be no Project Deployment Configuration Reference for Senlin.
Senlin tutorials look very well documented and caught my interest and I'm excited to try it in the future. I do not currently have a use case for this software, but its too cool looking not to try anyway. I may try installing it someday in the future as an experiment.
AFAIK this is a live project. Then again I haven't tried using it.
Trove
This is yet another *aaS project, this one specializing in databases, that amounts to wrapping a docker container around the OpenStack Keystone system for auth and quotas and such.
https://docs.openstack.org/trove/yoga/
There seems to be no Kolla-Ansible Project Deployment Configuration Reference for Trove.
As configured by Kolla-Ansible, Trove is ready to use in the sense that all the infrastructure is set up, but there are no guest images uploaded and no datastores configured.
Building a Trove guest image notes:
https://docs.openstack.org/trove/latest/admin/building_guest_images.html
mkdir images
git clone https://opendev.org/openstack/trove
cd trove/integration/scripts
./trovestack build-image
openstack image create trove-guest-ubuntu-bionic \
--private \
--disk-format qcow2 \
--container-format bare \
--tag trove --tag mysql \
--file ~/images/trove-guest-ubuntu-bionic-dev.qcow2
openstack datastore version create 5.7.29 mysql mysql "" \
--image-tags trove,mysql \
--active --default
trove-manage db_load_datastore_config_parameters mysql 5.7.29 ~trove/trove/templates/mysql/validation-rules.json
Fails with:
2022-07-11 23:15:31.903 | ERROR: Cannot install trove==17.1.0.dev36 because these package versions have conflicting
dependencies.
2022-07-11 23:15:31.903 |
2022-07-11 23:15:31.903 | The conflict is caused by:
2022-07-11 23:15:31.903 | trove 17.1.0.dev36 depends on Jinja2>=2.10
2022-07-11 23:15:31.903 | The user requested (constraint) jinja2===3.1.2
I filed a bug on the inability to build Trove images:
https://storyboard.openstack.org/#!/story/2010137
I like the idea of integrated backups in Trove. However it seems like a HUGE amount of work to set up, compared to a couple lines in a Heat Orchestration Template to spawn off a Zun container of any arbitrary DBMS, whichever MySQL version I would like at this moment, etc.
Octavia
https://docs.openstack.org/octavia/yoga/
Kolla-Ansible Project Deployment Configuration Reference (PDCR) for Octavia
https://docs.openstack.org/kolla-ansible/yoga/reference/networking/octavia.html
I don't have a use case for a load balancer at this time. If I did, I would install a software LB of my own choice on an instance, or in a Docker Zun Container.
Watcher
Watcher seems a good idea in concept. However, it seems dead.
https://docs.openstack.org/watcher/yoga/
I could not find a Project Deployment Configuration Reference (PDCR) for Watcher.
I tried to install Watcher, but it repeatedly restarts its containers every 30 seconds I assume its crashing. Then, I noticed Watcher's horizon dashboard gets weird and crashes also.
So... removing watcher. Ironically on my hand installed Plan 1.0 cluster, it "worked" or at least it didn't crash constantly.
Freezer
Integrated backup service in OpenStack sounded very exciting. If it were not a dead project I'd surely use it on a regular basis.
https://docs.openstack.org/freezer/yoga/
There seems to be no Project Deployment Configuration Reference (PDCR) for Freezer.
Install fails. Domain_name error. There's a bug open at storyboard and launchpad. Freezer project seems dead, unfortunately.
https://storyboard.openstack.org/#!/story/2009936
https://bugs.launchpad.net/kolla-ansible/+bug/1961430
Conclusion
The idea of deeply integrating *aaS products into OpenStack sounds very appealing as a way to leverage Keystone and HEAT and generally integrate with the other services. However, none of the *aaS integrate with the exception of Designate which integrates pretty well with Neutron. All the *aaS projects other than Designate seem to either not fit my needs so I didn't try them or I tried them and they are dead. Luckily in all cases technology has marched on, and if I need an instant MySQL, as an example of a *aaS product, I can quickly and easily spawn a Docker container in Zun which works great and I can orchestrate with Heat Templates, and its easier to admin than an "embedded" OpenStack project. So in summary, these projects either don't meet my needs, or they're dead projects that no longer work, but I don't mind.
Tomorrow, the conclusion post for the Plan 2.0 era.
Stay tuned for the next chapter!
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.