Cloud Client 17 proposal

The Nimbus cloud client has traditionally supported operating against a single Nimbus cloud, which is configured in the conf/cloud.properties file. You can also specify an alternate cloud configuration using the --conf argument to the cloud client.

Because of changes introduced by cumulus and the desire to provide a smoother experience when using multiple clouds, we are considering making changes to the configuration system.

Goals

• Better support of multiple clouds, including with each their cloud-specific X509 and Cumulus tokens.
• Simplified ability for admin to create a distributable package of cloud properties and X509 credentials that a user can install without clobbering the configuration of other clouds.
• Steps towards moving configuration and transient data out of nimbus-cloud-client-###/ directory and into ~/.nimbus/ — facilitate apt-get install in the future.

Proposal

Configuration will be divided between two types of files: general, and cloud specific. These configuration files can be located either in the cloud client conf/ directory or in the user’s home directory, in ~/.nimbus/. The cloud client will support targeting a specific cloud using a command line argument and will fall back to a default if the argument is not provided.

Configuration layout

~/.nimbus/
    cloud-client.conf
    clouds/
        foxtrot.conf
    trusted-certs/
        d5cb8777.0

cloud-client/
    conf/
        cloud-client.conf
        clouds/
            hotel.conf
            foxtrot.conf

Configuration search order

• cloud-client.conf loaded from cloud-client first, then overridden by ~/.nimbus/
• clouds/*.conf loaded from cloud-client first, then overridden by ~/.nimbus/

When performing an operation on a specific cloud, say “hotel”, the following configs are
consulted in this order. Any missing files are omitted:

1. cloud-client/conf/cloud-client.conf
2. ~/.nimbus/cloud-client.conf
3. cloud-client/conf/clouds/hotel.conf
4. ~/.nimbus/clouds/hotel.conf
5. command line arguments

The configs that are consulted later in the process will override the earlier ones.

New cloud client arguments

--cloud foxtrot if this is omitted, a default.cloud property is consulted (from cloud-client.conf)

--list-clouds prints out list of available clouds and some basic info about them.

New properties

The default cloud property specifies which cloud to use when the --cloud argument is omitted from the command. This property only makes sense in one of the cloud-client.conf files.

default.cloud = hotel

In order to support existing cloud.properties, we could also grandfather in this file. If you have a cloud-client/conf/cloud.properties and you do not specify --cloud on the command line, it uses the cloud.properties configuration and ignores default.cloud.

Cloud configuration distribution

An admin for e.g. the “hotel” cloud can create a tarball containing the following files:

hotel.conf
hotel-usercert.pem
hotel-userkey.pem

The hotel.conf file would contain relative path references to the cert and key as well as all other necessary cloud configuration for hotel.

The user could retrieve this tarball securely and run the following commands.

$ mkdir -p ~/.nimbus/clouds/
$ cd ~/.nimbus/clouds/
$ tar xvfz ~/my-hotel-config.tar.gz

CA certificates that need to be trusted can be placed in ~/.nimbus/trusted-certs/

Cloud configuration/credential separation

A possibility now is that conf/clouds/hotel.conf file can be separate from a different ~/.nimbus/clouds/hotel.conf file that only contains secrets.

Consider the situation where an administrator needs to change a setting that would affect all of the cloud’s users but their credentials are going to stay the same. In that case, being able to say “replace cloud-client/conf/hotel.conf with this new file” is easier than saying “replace the following properties in hotel.conf”

Another situation might be that a ‘consortium’ of clouds wants to publicly distribute a cloud-client tarball with a prepopulated conf directory. You can use this out of the box as long as you have your credentials in ~/.nimbus. A very similar situation is where a sitewide installation has cloud-client on the default PATH with a default set of configurations that the system’s users should be using with their credentials locked away private in ~/.nimbus