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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
