Sprint Report: Identity Sprint - Dunedin

[Tim Penhey]

Hi folks,

Last week the Onyx (Dave, Jesse, Menno, Tim) and Emerald (Casey, Matty,
Domas) teams met along with William to start work on the full support of
users within Juju.

This work builds on many other pieces that work together to be the
foundation of this work.

The work focused around the following parts:
 * representing users in a database with multiple environments
 * changing the format of the cached juju environment files on the
client machines
 * providing a versioned login method in the API to handle providing a
more detailed response
 * working on the upgrade process to have the possibly multiple state
server machines synchronize their updates
 * writing out a valid connection file at bootstrap time

Probably the biggest benefit of having everyone in the same room at the
same time was to ensure that people had a common understanding of the
work, architecture and plan.

This is continuing work and likely to be quite a number of weeks before
full completion with full command line control.

The final end point of this work also really includes the
multi-environment work when we can have a bootstrapped environment and run:
	juju create-environment another-one ...

Which will create a second environment in the same database.

Tim


= More details =

Users:

There is a user collection in the database now, and this will continue
to represent the users that are local to that database.  User tags gain
a "provider".  The provider is the "thing" that is responsible for
authenticating the user.  For migrated users in existing environments,
and for other users created through the command-line, this is "local".
This allows us the flexibility of adding remote users later, where the
authentication is managed elsewhere.

Environment User (EnvUsers collection):

This is "a user in an environment".  The user field of this may refer to
a local user, or to a remote user.  In the cases where it is a remote
user, there is no User record in the database for that user, just the
reference to the remote user in the environment.

Until we get authorization done, the mere presence of an environment
user document for the environment means that the user has full admin
rights as if they created the environment themselves.

The authorization implementation is likely to be the next thing after
the multi-environment work.

Connection files (replacing .jenv)

The connection files effectively need to store the same information as
the existing jenv files, but slightly more split out.  It will soon be
possible to have multiple environments accessible through one set of API
end-points. Since the API end-points can change over time (with high
availability), we only want to update this in one place.  The canonical
name (pun intended) of an environment is now a pair of UUIDs, one
describing the environment that is running the API end-points, and the
other is the UUID of the environment within the database connected to by
the API.  The connection files are now an alias to an environment, and
records the UUID pair, along with the user that is being used. The
server file contains the CACert, API end-points, and cached credentials
for the local users.  Remote users also have another file that just
stores the cached credentials for that user.

API Login v2

Currently the API versioning is only on the functions after login. We
wanted to change the results from Login itself.  Work is currently in
review to allow this.

API endpoints

The work for logins can now change the endpoint that we hand back once
the user has logged in.  This means that we can support 1.18 clients
that expect to access the API at the root, and newer clients that expect
a user manager and environment manager at the API root, and access
environments through a path that includes the environment UUID.


The changes to the command line interface is still being finalised.

Tim