Open Stack

On 12.12.2013 09:48, Ladislav Smola wrote:
> On 12/11/2013 06:15 PM, Jiří Stránský wrote:
>> On 11.12.2013 17:13, Ladislav Smola wrote:
>>> Hi,
>>>
>>> thanks for starting this conversation.
>>> I will take it little side ways. I think we should be asking why have we
>>> needed the tuskar-api. It has done some more complex logic (e.g.
>>> building a heat template) or storing additional info, not supported by
>>> the services we use (like rack associations).
>>> That is a perfectly fine use-case of introducing tuskar-api.
>>>
>>> Although now, when everything is shifting to the services themselves, we
>>> don't need tuskar-api for that kind of stuff. Can you please list what
>>> complex operations are left, that should be done in tuskar? I think
>>> discussing concrete stuff would be best.
>>
>> I believe this is an orthogonal discussion. Regardless if we have
>> tuskar-api or not, Tuskar UI is going to be an "integrated face" over
>> multiple services (Heat, Ironic, maybe others), and i'd think we could
>> use a CLI counterpart too.
>>
>
> Well that is how dashboard works. I think point of Service oriented
> architecture is to use the services. Not trying to integrate it on the
> other end.

Yeah i don't want to integrate it on the API side. But if there's some 
logic we're building on top of the APIs (and i believe there is, i gave 
an example in my initial e-mail), i'd like to have the same logic code 
used in CLI and UI. And the easiest way to do this is to pull the logic 
out of UI into some library, ideally directly into python-tuskarclient, 
since UI already depends on it anyway (and i also believe tuskarclient 
is one of the possible correct places for that code to live in, if we 
make it a separate namespace).

<snip>

> Let's build the whole story in
> UI, then we can see if there are abstractions that are usable for both
> CLI and UI. In the mean time, you will have CLI maybe little harder to
> use, but more general.

Yeah i think i'd be fine with that. As i wrote in my initial e-mail, we 
might want to keep a thicker UI initially (maybe for the Icehouse 
release) to avoid doing too much refactoring at the same time. But 
eventually, i think we should pull the logic out, so that CLI and UI 
have comparable capabilities, including ease of use.

Thanks for the feedback :)

Jirka