The Saxophone is a harsh mistress. She demands attention every day. A musician friend once quoted to me: “Skip a day and you know. Skip two days and your friends know. Skip three days and everyone knows.” That quote keeps me practising nightly.
I’ve set up MySQL enough times figuring things out from docs that I decided I need to take notes.
This is a destructive re-install. Don’t do this if you value your data. In fact, just don’t do this.
Ever get that feeling that an epiphany is right around the corner? I spent a good portion of the OpenStack summit with that feeling. I knew that it would not be earth shattering, or lead me to want to rewrite Keystone, but rather a clarification of how a bunch of things should fall together. The “click” happened on the second to last day, and it can be summarized in a few key points.
OpenStack Keystone tokens can become too big to fit in the headers between mod_wsgi and the WSGI applications. Compression mitigates the problem somewhat, but if token sizes continue to grow, eventually they outpace the benefits of compression. How can we keep them to a minimal size?
In my last post, I discussed how to extract the signing information out of a token. But just because the signature on a document is valid does not mean that the user who signed it was authorized to do so. How can we got from a signature to validating a token? Can we use that same mechanism to sign other OpenStack messages?
The specification For multiple signers requires a mechanism to determine who signed the token and then determine I’d the signer had the authority to issue a token for the scope of the token. These are the steps he he necessary to perform that validation.
I have a Devstack setup. I’ve hacked the Keystone repo to add some cool feature. I want to test it out with an RDO deployment. How do I make my own RPM for the RDO system?
This is not a how to. This is more like a police log.
You have a cloud, I have a cloud.
Neither of use are willing to surrender control of our OpenStack deployments, but we need to inter-operate.
We both have Keystone servers. Those servers are the system of record for user authorization through out our respective deployments. We each wish to maintain control of our assignments. How can we make a set of resources that can be shared? It can’t be done today. Here is why not, and how to make it possible.
Keystone supports multiple backend for Identity. While SQL is the default, LDAP is one of the most used. With Federation protocols, the user data won’t even be stored in the identity backend at all. All three of these approaches have different use cases, and all work together. The way that that I’ve come to think of them is as three types of Keystone users: employees, partners, and customers. Take the following as a metaphor, not literal truth.