Open Stack

On 26.2.2014 20:43, Jay Dobies wrote:
>> I'd say it's still an open question whether we'll want to give better UX
>> than that ^^ and at what cost (this is very much tied to the benefits
>> and drawbacks of various solutions we discussed in December [1]). All in
>> all it's not as bad as i expected it to be back then [1]. The fact that
>> we keep Tuskar API as a layer in front of Heat means that CLI user
>> doesn't care about calling merge.py and creating Heat stack manually,
>> which is great.
>
> I agree that it's great that Heat is abstracted away. I also agree that
> it's not as bad as I too expected it to be.
>
> But generally speaking, I think it's not an ideal user experience. A few
> things jump out at me:
>
> * We currently have glance, nova, and tuskar represented. We'll likely
> need something to ceilometer as well for gathering metrics and
> configuring notifications (I assume the notifications will fall under
> that, but come with me on it).
>
> That's a lot for an end user to comprehend and remember, which concerns
> me for both adoption and long term usage. Even in the interim when a
> user remembers nova is related to node stuff, doing a --help on nova is
> huge.

+1

>
> That's going to put a lot of stress on our ability to document our
> prescribed path. It will be tricky for us to keep track of the relevant
> commands and still point to the other project client documentation so as
> to not duplicate it all.

+1

>
> * Even at this level, it exposes the underlying guts. There are calls to
> nova baremetal listed in there, but eventually those will turn into
> ironic calls. It doesn't give us a ton of flexibility in terms of
> underlying technology if that knowledge bubbles up to the end user that way.
>
> * This is a good view into what third-party integrators are going to
> face if they choose to skip our UIs and go directly to the REST APIs.
>
>
> I like the notion of OpenStackClient. I'll talk ideals for a second. If
> we had a standard framework and each project provided a command
> abstraction that plugged in, we could pick and choose what we included
> under the Tuskar umbrella. Advanced users with particular needs could go
> directly to the project clients if needed.
>
> I think this could go beyond usefulness for Tuskar as well. On a
> previous project, I wrote a pluggable client framework, allowing the end
> user to add their own commands that put a custom spin on what data was
> returned or how it was rendered. That's a level between being locked
> into what we decide the UX should be and having to go directly to the
> REST APIs themselves.
>
> That said, I know that's a huge undertaking to get OpenStack in general
> to buy into. I'll leave it more that I think it is a lesser UX (not even
> saying bad, just not great) to have so much for the end user to digest
> to attempt to even play with it. I'm more of the mentality of a unified
> TripleO CLI that would be catered towards handling TripleO stuffs. Short
> of OpenStackClient, I realize I'm not exactly in the majority here, but
> figured it didn't hurt to spell out my opinion  :)

Yeah i think having a unified TripleO CLI would be a great boost for the 
CLI user experience, and it would solve the problems we pointed out. 
It's another thing that we'd have to commit to maintain, but i hope CLI 
UX is enough priority that it should be fine to spend the dev time there.


Thanks

Jirka