Adventures of a Small Time OpenStack Sysadmin Chapter 012 - OpenStack Keystone Identity Service Installation

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 012 - OpenStack Keystone Identity Service Installation

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

Ansible installs/upgrades the package, everything else is manual.

Installation of this service was uneventful.  Lots of cut and paste from the installation guide into the console.

I used the CLI client to create the sample domain, projects, roles, etc.

It takes awhile to wrap your head around the right way to use Keystone's features.  At first I just used random designs from the docs.  Eventually I set up one giant project, at least I set it up correctly, and put everything "production" into that giant project.  That makes the Web UI very slow and clumsy to operate.

Not to jump too far ahead, but in the end I set up projects in Keystone more or less along role and project lines.  I have the following projects at this time:

admin: test experiments while logged in as admin, which you shouldn't do normally anyway.

enduser: literal enduser instances, hosts that I log into on a day to day basis to do "stuff".  Things you'd have an Apache Guacamole entry to access.

infrastructure: instances and things that are required but rarely directly touched, think of DHCP servers or DNS servers or similar.  If a user would directly touch it, like Booksonic or Apache Guacamole, it belongs in "server" project.

iot: this is an enduser project with multiple images.  More or less the entire Eclipse IoT software suite.

rutherford: another enduser project.  Kind of a demonstration of computational physics simulations mixed with a demonstration of OpenStack.  More detail is beyond the scope of this blog post, or even this series.  Watch for an interesting Youtube video in the future on the Spring City Solutions LLC channel!

server: this is server things endusers directly connect to, like Apache Guacamole.  If its important and required but end users don't log in directly, like DHCP, that would belong in the "infrastructure" project.  Think of Emby server, or minecraft server, or Booksonic server.

Looking back, from the time of writing this all the way back to the earliest days, this project organization strategy has worked very well.

The docs emphasize making your own roles in Keystone, but this seems a non-productive activity.  Nice to know its possible and nice to know how if you need to, but under normal conditions, why?

For troubleshooting experience, everyone involved with Keystone should replicate the work in the Verification section of the chapter, just to have the experience of having obtained a token.  Never know when this troubleshooting experience will be necessary.

https://docs.openstack.org/keystone/yoga/install/keystone-verify-ubuntu.html

Stay tuned for the next chapter!