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 022 - OpenStack Heat Orchestration Service
My reference for installing Heat:
https://docs.openstack.org/heat/yoga/install/
Installation of Heat was uneventful and everything went per the manual.
Heat is probably the most fun I've had with OpenStack. For something named "Heat" its very cooooool.
Originally, in Plan 1.0 timeframe, I automated all the infrastructure and some instances using the openstack cli and scripts and frankly just experimented doing stuff by hand in the web UI. Slow, tedious, prone to human error, but it "works".
The problem I rapidly ran into is scripting is very slow, if you change one thing but have to apply a script of a hundred things it takes awhile. Also its kind of unpredictable, from memory, which components are idempotent and therefore safe, and which are not. I vaguely recall project create scripting was safe because project names are unique so running the script over and over is quite safe, at least WRT creating projects. However, it was something like Neutron subnets where the system simply doesn't care and you can create multiple identical-ish subnets by re-running the config script, one extra subnet created each time you re-run the script. Well, maybe it wasn't Neutron subnets, but it was some "big problem", whatever it was, anyway. The stereotypical script way to fix that situation is to delete the component before adding it, which is great during initial development but once stuff depends on it, its not funny anymore to delete and create things that other components depend upon.
Which is why people invented orchestration a long time ago. Orchestration looks about the same as scripting, to a first approximation, and on an empty green field deployment it behaves exactly the same. However, the algorithm for scripting is the computer reads the script top to bottom one line at a time and does exactly that that line tells it to do, exactly, each time the script is run. And sometimes thats what you need for a process, but not everything is a process. Whereas orchestration repeatedly re-reads thru the file trying its best each time to make real-world things match what it reads in the template, skipping over everything that already matches, until it can scan the entire template and find no mismatch with reality, at which point the terminology gets weird and it sets its status to "created" or "updated" depending on starting conditions, which is kind of dumb but whatever. The status of a successfully completed orchestration should use a more intuitively descriptive status word like "matches", not "created".
In Plan 2.0 everything is orchestrated except setting my personal user's password and a couple microscopic things like that. Its really cool being able to add or fine tune some minor detail and in seconds, reality matches my updated template. And of course templates are source-code-alike text, you can store them on GitLab and so forth.
If you're experienced with Ansible and related technologies, at a very detailed level they are scripting in the sense of "in order, top to bottom" but at a distant high level Ansible is used to reach orchestration-ish goals very successfully.
After installation, before you know what you're doing, you should probably examine this vast collection of useful Heat template examples, if you can't find something cool here, you need to recalibration your concept of cool:
https://opendev.org/openstack/heat-templates
During actual production use, I spend a lot of time at this URL titled "OpenStack Resource Types", its a really nice reference-class document:
https://docs.openstack.org/heat/yoga/template_guide/openstack.html
Pretty much everything in the Web UI, REST API, CLI, Python library, and Heat Resource match in some way, even if its displayed or described somewhat differently, each conceptual activity has a matching doppelgänger in the other services. I like that aspect of OpenStack, its so versatile, it doesn't really matter if you're writing REST API calls or clicking web UI by hand or templating, its always possible to do everything and its all interoperable.
Today's blogpost might have been a sappy emotional love-letter to the Heat Orchestration Service, but tomorrow's topic is Magnum, which is, um, not. That should sound ominous, because it is, LOL.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.