Open Stack

One of the things I like about TripleO is the way you can use the
Undercloud remotely via its APIs to drive everything about your
deployment. We don't prevent you from shelling into your undercloud
though, and more recently with the switch to use instack and python-
tripleoclient our upstream CI documentation has actually moved towards
a model where we use the undercloud as a convenience to "stage" things
like building images, creating ssh keys for deployment. It is okay to
do this to save resources, but it shouldn't be be required. I'd like to
maintain a clear line which maintains the undercloud primarily as a
black box to be used via API's, not as something you shell into to
manage your overcloud.

A couple of examples:

We've actually got code in python-tripleoclient today that requires you
to execute some commands on the undercloud itself. The function to
build images [1] actually copies the IPA ramdisk and kernel in an HTTP
root for the Ironic inspector. This is somewhat optional functionality
(I can build my own images, and avoid the ironic inspector) but it
demonstrates how small feature addition to the client tooling forces
you to execute it on the undercloud rather than using API's. I suppose
I'd like to see us consider alternative approaches to this problem like
perhaps using a Mistral workflow to execute the same code on the
undercloud itself. We could still initiatiate it via python-
tripleoclient but we'd no longer require root shell access to do so.

A second example caught my attention recently was a patch to add
Ansible support to the undercloud here [2]. I really like to idea that
we would integrate with Ansible and provide options to generate or
perhaps auto configure the inventory via our undercloud APIs. What I'm
not as keen on is forcing the user to shell into the undercloud to take
advantage of these features. I happen to create my overcloud remotely
(with my ssh private keys on my laptop), and my use case for Ansible
integration would be much the same. I would likely want to use Ansible
directly from my laptop where my ssh keys reside. This isn't to say
that someone couldn't do the same thing on an undercloud by creating
their own home directory, and using the same client tooling. We could
actually support both models quite well. But where we implement these
types of features does matter, and may force operators and end users
into unwanted workflow changes (storing ssh keys on the undercloud,
etc).

Dan


[1] http://git.openstack.org/cgit/openstack/python-tripleoclient/tree/t
ripleoclient/v1/overcloud_image.py#n792
[2] https://review.openstack.org/#/c/277688/