(packaging) Update Modulefile, CHANGELOG for 1.0.9
Add `google-api-client` to the Gemfile

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Add initial GCE support: Google API authentication

This implements the first phase of Google Compute Engine support to Cloud
Provisioner, by implementing authentication support.  This uses the OAuth2
installed application workflow, which seems to be the best match to what is
offered by the cloud console, and our local needs.

This implements token storage, refresh, and a web browser based access
request process.  This is initially entered by the user through the `register`
action on the `node_gce` face.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `list` operation for instances

This provides a read-only view of instances -- globally or restricted to a
single zone.

It also includes human focused rendering support; part of this is wired in by
adding a custom `to_s` method to the "instance" instances returned by the
Google API.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement basic `create` operation for instances

This wires up enough logic to allow instances to be created by node_gce: while
slightly limited in capabilities, it is sufficient to create an instances from
a stock or custom image using non-persistent local disk.

There are limitations:
 * no persistent disk support is yet available
 * networking is hard-coded to the `default` network
 * networking is hard-coded to use an ephemeral external IP

For all that, it provides mediated instance creation.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `delete` operation for instances

This completes the basic set of functionality available to GCE instances: we
can now delete them, removing the associated data and virtual machine.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `user` action to manage ssh key metadata

The GCE supplied images allow use of "metadata" on the instance to manage user
accounts; the `sshKeys` field is used by on-node software supplied in the
Google instances to keep a set of user accounts and their SSH keys in sync.

This provides an interactive mechanism to manage that structured data, adding
and removing users and their keys from the list.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement SSH key / account support at create time

This uses the `--login` and `--key` options that mirror those of the `puppet
node install` action to configure a single account at VM creation time.

As with other user management, this is implemented by setting the `sshKeys`
metadata item which is then used by software supplied by Google to create the
account and configure the SSH keys in place.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Move create operation in the file

This moves the implementation of create to a location next to bootstrap -- the
better to make visible the commonalities between them.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Extract common options into a procedural library

Because the design of faces makes it impossible to use conventional OO
solutions, such as inheritance or augmentation of classes, to solve the
problem of identical behaviour across disparate objects, we hit some
challenges when our actions share behaviours in the form of options.

This addresses that the same way the rest of the Cloud Provisioner code does,
by extracting the common options into a shared library of procedural code that
can be used to share execution and, by side effect, behaviour.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Extract "payload" options from other CloudPack install options

The original CloudPack design mashed together a pile of things into what it
called the "install" options -- which, unfortunately, included both some of
the payload options for installation and some of the authentication options
for how to connect to the target system.

This made it impossible to use that single original set of options with GCE,
since the security model is different enough to pose an unsolvable conflict.

This splits out those options into two components, installation and payload;
we only use the later in GCE, and retain the original definition of install
options for other 'clients' of CloudPack.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement bootstrapping of nodes with the GCE face.

This implements the `bootstrap` action, following the pattern of other Cloud
Provisioner faces.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Implement `ssh` action to help ssh in to instances

The `ssh` action will look up the host details, find a publicly visible IP
address, and then execute SSH to log in to the target machine.  This is a
convenience wrapper over doing the same work by hand.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #121 from daniel-pittman/add-google-compute-engine-support

Add google compute engine support
Update CHANGELOG, Modulefile for 1.1.0
Make GCE image search list comma separated

This updates the option for the image search project list to use commas (,)
rather than colons (:) to separate entries -- group affiliated projects are
identified with a colon in the GCE system, making them impossible to use in
the previous mode.

This also follows the convention of the upstream gcutil CLI.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Support `google_compute_engine` ssh key by default

The upstream gcutils tools default to the `google_compute_engine` ssh key;
this adapts our code to look for that first, and default to it if present.

If it does not exist we fall back to the normal `id_rsa` SSH credentials,
which follows the common practice of the rest of Cloud Provisioner.

Signed-off-by: Daniel Pittman <daniel@rimspace.net>
Merge pull request #122 from daniel-pittman/gce-avoid-colon-in-project-list

Make GCE image search list comma separated
Merge pull request #123 from daniel-pittman/gce-support-google-compute-ssh-key-too

Support `google_compute_engine` ssh key by default
(packaging) Update CHANGELOG, Modulefile for 1.1.1