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/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev