Pitching the Tent

Keystone: Less Overhead, More Federation

Keystone does not feature heavily in release messages; this central user management component in OpenStack typically runs in the background. Kilo introduces two major innovations for Keystone. On one hand, Keystone instances of multiple OpenStack clouds can be connected to create a federation network. Users can log into multiple clouds with the same credentials – a genuine convenience feature.

Almost more important, however, is the concept of Keystone Lightweight Tokens, a.k.a. KLWT. When users log into Keystone with a combination of their name and password, they receive a digital key, or token. They use this token to talk to other OpenStack services. Keystone stores each token it issues in a separate database. When users log into other services in the cloud with the token, these services query Keystone to see whether the token is still valid (Figure 2).

Figure 2: In Juno, Keystone stores a separate entry in the database for each token.

The need to save persistent tokens has led to unfortunate side effects, however. Besides performance hits, the Keystone token table tends to fill up in large OpenStack clouds, leaving administrators with no alternative but to clean up manually.

This is where Kilo's KLWTs enter the fray: The idea is that other services can validate tokens without the need to store the tokens centrally. A digital signature is used for this purpose: A KLWT contains user information, the user's project, the token issuing timestamp, and a digital signature.

Based on this signature, a service contacted by the user validates the token independently of Keystone. Morgan Fainberg, who was the Technical Lead for the Kilo release cycle, hopes that KLWTs will improve performance and make Keystone more reliable.

Nova as an Object

The Nova computing service offers several new functions in Kilo. The developers have been busy under the hood and have pushed on with converting to database objects (i.e., to the data model that Nova uses for its own database). Earlier Nova versions used SQL Alchemy to write individual records directly to the database.

That said, if you have a large computing framework with dozens of servers, it can be difficult to coordinate these writes in an orderly way. Conversion to objects was introduced back in the Havana version of OpenStack (2014). Since then, Nova has viewed instances as objects that it can modify directly in the database and using RPC calls across the whole cloud. The layer model therefore practically introduces an abstraction layer, which not all Nova components have used so far.

Kilo comes with many updates for this object functionality and facilitates updating Nova as a useful side effect. Thanks to the abstraction layer, increasingly smaller numbers of Nova components depend on the Nova database schema not changing between versions.

Cell Refresh

In Kilo, the OpenStack developers finally started to expand the Nova cell extension. Nova developers understand cells to be autonomous computing units interconnected via a central location. In Nova, it was impossible to use local databases and RPC services in the individual cells, which can cause a bottleneck if the individual cells are not adjacent on the network. The 2.0 cells in Kilo resolve this problem, thereby boosting their utility value.