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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
