[openstack-dev] [TripleO] Tuskar CLI after architecture changes

Ladislav Smola lsmola at redhat.com
Thu Dec 12 10:33:48 UTC 2013


On 12/12/2013 10:49 AM, Jiří Stránský wrote:
> 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

That sounds reasonable. Let's cross that bridge when we come to it. Like 
late I3 or J1.

Ladislav




More information about the OpenStack-dev mailing list