Open Stack

I'm going to reply to Dean's and James' posts in one shot because it 
imho makes most sense.

On 11.12.2013 17:00, Dean Troyer wrote:
> On Wed, Dec 11, 2013 at 9:35 AM, James Slagle <james.slagle at gmail.com>wrote:
>
>> On Wed, Dec 11, 2013 at 7:33 AM, Jiří Stránský <jistr at redhat.com> wrote:
>>> Previously, we had planned Tuskar arcitecture like this:
>>>
>>> tuskar-ui <-> tuskarclient <-> tuskar-api <-> heat-api|ironic-api|etc.
>>
>> To be clear, tuskarclient is just a library right?  So both the UI and
>> CLI use tuskarclient, at least was that the original plan?

Currently, tuskarclient is a library (Python bindings around tuskar-api) 
and CLI on top of that library (though the CLI is not as complete as the 
bindings).

> I would expect tuskarclient above to be the Python API bindings without the
> business logic.

Yes.

>
>
>> I don't think we want the business logic in the UI.
>
>
> +1
>
>
>>> Now this raises a question - how do we get CLI reasonably on par with
>>> abilities of the UI? (Or am i wrong that Anna the infrastructure
>>> administrator would want that?)
>>
>> IMO, we want an equivalent CLI and UI.  A big reason is so that it can
>> be sanely scripted/automated.

+1

>
>
> At a minimum you need to be sure that all of the atomic operations in your
> business logic are exposed via _some_ API.  ie, to script something the
> script may be where the business logic exists.
>
> Building on that is moving that logic into a library that calls multiple
> Python client APIs.  This may or may not be part of tuskarclient.
>
> The next step up is to put your business logic into what we used to call
> middleware, the layer between client and backend.  This is server-side and
> IMHO where it belongs.  This is really the ONLY way you can ensure that
> various clients get the same experience.
>
>
>> python-openstackclient consumes other clients :).  Ok, that's probably
>> not a great example :).
>>
>
> :) No, not really.  But it is also developing some 'value-added' functions
> that are cross-project APIs and has a similar problem.  So far that is just
> smoke and mirrors hiding the duck tape behind the scenes but it is not
> unlike some of the things that Horizon does for user convenience.
>
>
>> This approach makes the most sense to me.  python-tuskarclient would
>> make the decisions about if it can call the heat api directly, or the
>> tuskar api, or some other api.  The UI and CLI would then both use
>> python-tuskarclient.
>

Yeah making tuskarclient consume other clients seems most appealing to 
me as well. Solution 3 is very similar.

>
> If you do this keep the low-level API bindings separate from the
> higher-level logical API.

Agreed, this would be essential part of such solution. We'd need to have 
separate namespaces for the low-level Python API (thin wrapper over 
Tuskar REST API) vs. the high-level Python API (business logic on top of 
the internal low-level Python API and 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.)
>>
>> So, typically, I would say this is the right approach.  However given
>> what you pointed out above that sometimes we can use other API's
>> directly, we then have a seperation where sometimes you have to use
>> tuskar-api and sometimes you'd use heat/etc api.  By using
>> python-tuskarclient, you're really just pushing that abstraction into
>> a library instead of an API, and I think that makes some sense.
>
>
> Consider that pushig out to the client requires that the client be in sync
> with what is deployed.  You'll have to make sure your client logic can
> handle the multiple versions of server APIs that it will encounter.
>   Putting that server-side lets you stay in sync with the other OpenStack
> APIs you need to use.

Hmm this is quite a good argument for the server-side approach... But i 
wonder if it's worth the complexity of proxying some (possibly a lot of) 
API calls. If we don't need to keep any additional data about entities 
(by entities i mean Heat stacks, Ironic nodes, ...), then i think having 
a REST API just to ensure we can stay in sync with other services in the 
release is a bit overkill. I don't think maintaining compatibility of 
the client layer will be easy, but maintaining "the proxy" wouldn't be 
easy either imho.

>
>
>>> 3) Keep tuskar-api and python-tuskarclient thin, make another library
>>> sitting between Tuskar UI and all python-***clients. This new project
>> would
>>> contain the logic of using undercloud services to provide the "tuskar
>>> experience" it would expose python bindings for Tuskar UI and contain a
>> CLI.
>>> (Think of it like traditional python-*client but instead of consuming a
>> REST
>>> API, it would consume other python-*clients. I wonder if this is
>>> overengineering. We might end up with too many projects doing too few
>>> things? :) )
>>
>> I don't follow how this new library would be different from
>> python-tuskarclient.  Unless I'm just misinterpreting what
>> python-tuskarclient is meant to be, which may very well be true :).

1 and 3 are indeed very similar. The only difference is that in 3 the 
high-level Python API and CLI would be a separate project (packaged 
separately).

>
>
> This is essentially what I suggested above.  It need not be a separate repo
> or installable package, but the internal API should have its own
> namespace/modules/whatever.

Yeah i think separate namespace should be sufficient, to keep things simple.


Thanks! :)

Jirka