Open Stack

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.

>
> There can be a CLI or API deployment story using Openstack services, not
> necessarily calling only tuskar-cli and api as proxies.
> E.g. in documentation you will have
>
> now create the stack by: heat stack-create params
>
> it's much better than:
> You can create stack by tuskar-deploy params, which actually calls heat
> stack-create params
>
> What is wrong about calling the original services? Why do we want to
> hide it?

Well, imho that's a bit like asking "why should we have command-line 
e-mail clients if the terminal users can simply write SMTP protocol by 
hand" :) Or, to be closer to our topic: "Why build a Tuskar UI when user 
can use Dashboard to deploy overcloud - just upload the heat template, 
and provide the params."

There's nothing essentially wrong about using heat command line or 
Dashboard for deploying overcloud i believe, other than that it's not 
very user friendly. That's the whole reason why we build Tuskar UI in 
the first place, i'd say. And my subjective opinion is that CLI users 
should be able to work on a similar level of abstraction.

Jirka