Open Stack

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.

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

Well it seems to me like writing an email client over an email client, 
not over SMTP.

"Why build a Tuskar UI when user can use Dashboard to deploy overcloud - 
just upload the heat template, and provide the params."
Well yeah, I think it's where we can be heading. User should be able to 
switch the the Heat template (e.g. a Heat template with kickass 
distributed architecture). User will be able to have many overclouds 
(stacks) each with different Heat template.

So yes, I still see openstack as a complex application you deploy via 
Heat. I can be wrong though and we might need some CLI abstraction. 
Though that is why the sysadmins are writing scripts for themselves, 
they like to build their own abstractions from the atomic operations.

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

Dashboard doesn't fit very well for deploying and managing hardware. 
That is why we build separate UI, I think. Though that doesn't mean we 
can't just use the APIs in a different way. All I am saying is, let's 
not build this abstraction in advance. 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.

> Jirka