Adventures of a Small Time OpenStack Sysadmin Chapter 023 - OpenStack Magnum Container Infrastructure Service

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 023 - OpenStack Magnum Container Infrastructure Service

My reference for installing Magnum:

https://docs.openstack.org/magnum/yoga/install/

Installation of Magnum was uneventful and everything went per the manual.  That was the good news.  Now, for the rest of the story...

One minor bug in Magnum install docs is the python package name for the client is listed as python-magnumclient but its actually python3-magnumclient.  I opened a bug and provided the exact file to change and the solution at:

https://storyboard.openstack.org/#!/story/2010156

I also ran into the template problem I've run into other times, where the default "region_name = regionOne" but region names are caps sensitive so that needs to be changed to match everything else "region_name = RegionOne".  It gets to the point where instead of filing a bug on seemingly every OpenStack service, I should file a bug on Keystone and people doing manual installs should set it to "region_name = regionOne" to match every other service in the overall project.  Whatever, so over that now, did not feel like filing a bug.  Just posting this so people know its an issue.

My thought process in deciding to use Magnum went like this:  On my old VMware cluster I have CONSIDERABLE experience setting up virtual hosts, in fact bunches of virtual hosts, to act as Docker Container-containers, and Docker Swarm members, and K8S cluster members and stuff like that, all via various forms of manual labor up to extensive orchestration and automation using various VMware products and Ansible etc, so the idea of being able to spawn off a Docker Swarm at a click of a button instead of taking maybe thirty minutes to mostly automate and orchestrate a swarm seems appealing.  Also I tried setting up Zun/Kuryr container infrastructure by hand and pretty much failed and decided if I want container infra I need to wait for Plan 2.0 and Kolla-Ansible where it was supposedly effortless, which turned out to be pretty accurate.  So in the interim I had the brainstorm that anything that runs on simple Docker containers can be wedged into running on a Docker Swarm, even on a crazy one host Docker Swarm.  So I could use Magnum and its Docker Swarms to replace the uninstallable (by hand) Zun/Kuryr.  This seemed like a great way to host Docker Containers during the Plan 1.0 era.  During Plan 2.0 era I'd just stick containers in Zun, so Magnum would be a temporary band-aid.  I also had a third reason to install, Magnum might be fun for deploying temporary clusters for educational and testing purposes.

So... I know online I've read a lot of stuff about people using Magnum to spin up K8S test clusters and nobody uses it for Docker anymore, etc.  But I had my reasons or justifications for trying to make it work.

It did not work.

"ERROR: Property error: : resources.api_lb.properties: : Property allowed_cidrs not assigned"

Great, just great...  "Push button receive cluster" sounds like a useful productive service, "Push button receive mysterious failure message" not so useful of a service.

The problem, oft seen in OpenStack, of trying to hide and abstract a standard service away behind custom code, is its very difficult to troubleshoot someone else's hidden abstraction code.  So its easier for me to polish up my orchestration and automation to a fine shine, and use that to spin up my own docker swarms and docker container-containers and K3S clusters, than to troubleshoot someone else's efforts to abstract and automate.  I ran into this problem later with Trove and Manila and some other service-services; I already have orchestration and automation of certain services, and I fully understand my orchestration and automation and my backup systems and troubleshooting access, and its not really worth the investment of large amounts of my time to understand someone else's opaque system, especially if theirs doesn't work at all in comparison my systems work great.

So I got VERY frustrated with Magnum after a couple days struggle, sent a post to the OpenStack users mailing list asking if anyone else has a working Magnum installation and can collaborate to get it working and/or improve the software and docs, heard crickets, tossed it, and moved on with life.

If I need a Docker Swarm I have Heat templates and Ansible and they can spin up one up faster than I can fix Magnum, and even if Magnum worked its possible my scripts might work just as fast as Magnum anyway.  Its kind of like the pragmatic way to fix bugs in Trove, where the fastest way to fix a Trove bug is to toss a Docker Mysql:latest container into Zun and no longer use Trove, LOL, I can be up and running in less than a minute, fixing Trove would take a lot longer than that minute.  The entire Trove project can be replaced by a single Zun Resource line in a template.  Much like Magnum.

Yeah, I got a little frustrated with this one.  Well, maybe a lot frustrated.  Bye Magnum, I'll replace you with a very small shell script!

As a change of pace, tomorrow is not Friday, its Ceilometer Day.

Stay tuned for the next chapter!