Open Stack

On Wed, 2013-12-11 at 13:33 +0100, Jiří Stránský wrote:
> Hi all,
> 
> TL;DR: I believe that "As an infrastructure administrator, Anna wants a 
> CLI for managing the deployment providing the same fundamental features 
> as UI." With the planned architecture changes (making tuskar-api thinner 
> and getting rid of proxying to other services), there's not an obvious 
> way to achieve that. We need to figure this out. I present a few options 
> and look forward for feedback.
..

> 1) Make a thicker python-tuskarclient and put the business logic there. 
> Make it consume other python-*clients. (This is an unusual approach 
> though, i'm not aware of any python-*client that would consume and 
> integrate other python-*clients.)
> 
> 2) Make a thicker tuskar-api and put the business logic there. (This is 
> the original approach with consuming other services from tuskar-api. The 
> feedback on this approach was mostly negative though.)

FWIW, I think these are the two most plausible options right now.

My instinct is that tuskar could be a stateless service which merely
contains the business logic between the UI/CLI and the various OpenStack
services.

That would be a first (i.e. an OpenStack service which doesn't have a
DB) and it is somewhat hard to justify. I'd be up for us pushing tuskar
as a purely client-side library used by the UI/CLI (i.e. 1) as far it
can go until we hit actual cases where we need (2).

One example worth thinking through though - clicking "deploy my
overcloud" will generate a Heat template and sent to the Heat API.

The Heat template will be fairly closely tied to the overcloud images
(i.e. the actual image contents) we're deploying - e.g. the template
will have metadata which is specific to what's in the images.

With the UI, you can see that working fine - the user is just using a UI
that was deployed with the undercloud.

With the CLI, it is probably not running on undercloud machines. Perhaps
your undercloud was deployed a while ago and you've just installed the
latest TripleO client-side CLI from PyPI. With other OpenStack clients
we say that newer versions of the CLI should support all/most older
versions of the REST APIs.

Having the template generation behind a (stateless) REST API could allow
us to define an API which expresses "deploy my overcloud" and not have
the client so tied to a specific undercloud version.

Mark.