Open Stack

On 12.12.2013 17:10, Mark McLoughlin wrote:
> 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).

For the features that we identified for Icehouse, we probably don't need 
to store any data necessarily. But going forward, it's not entirely 
sure. We had a chat and identified some data that is probably not suited 
for storing in any of the other services (at least in their current state):

* Roles (like Compute, Controller, Object Storage, Block Storage) - for 
Icehouse we'll have these 4 roles hardcoded. Going forward, it's 
probable that we'll want to let admins define their own roles. (Is there 
an existing OpenStack concept that we could map Roles onto? Something 
similar to using Flavors as hardware profiles? I'm not aware of any.)

* Links to Flavors to use with the roles - to define on what hardware 
can a particular Role be deployed. For Icehouse we assume homogenous 
hardware.

* Links to Images for use with the Role/Flavor pairs - we'll have 
hardcoded Image names for those hardcoded Roles in Icehouse. Going 
forward, having multiple undercloud Flavors associated with a Role, 
maybe each [Role-Flavor] pair should have it's own image link defined - 
some hardware types (Flavors) might require special drivers in the image.

* Overcloud heat template - for Icehouse it's quite possible it might be 
hardcoded as well and we could just just use heat params to set it up, 
though i'm not 100% sure about that. Going forward, assuming dynamic 
Roles, we'll need to generate it.

^ So all these things could probably be hardcoded for Icehouse, but not 
in the future. Guys suggested that if we'll be storing them eventually 
anyway, we might build these things into Tuskar API right now (and 
return hardcoded values for now, allow modification post-Icehouse). That 
seems ok to me. The other approach of having all this hardcoding 
initially done in a library seems ok to me too.

I'm not 100% sure that we cannot store some of this info in existing 
APIs, but it didn't seem so to me (to us). We've talked briefly about 
using Swift for it, but looking back on the list i wrote, it doesn't 
seem as very Swift-suited data.

>
> 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.

Yeah i see that advantage of making it an API, Dean pointed this out 
too. The combination of this and the fact that we'll need to store the 
Roles and related data eventually anyway might be the tipping point.


Thanks! :)

Jirka