Open Stack

> Hello,
>
> i went through the CLI way of deploying overcloud, so if you're
> interested what's the workflow, here it is:
>
> https://gist.github.com/jistr/9228638

This is excellent to see it all laid out like this, thanks for writing 
it up.

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

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.

* 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  :)


> In general the CLI workflow is on the same conceptual level as Tuskar
> UI, so that's fine, we just need to use more commands than "tuskar".
>
> There's one naming mismatch though -- Tuskar UI doesn't use Horizon's
> Flavor management, but implements its own and calls it Node Profiles.
> I'm a bit hesitant to do the same thing on CLI -- the most obvious
> option would be to make python-tuskarclient depend on python-novaclient
> and use a renamed Flavor management CLI. But that's wrong and high cost
> given that it's only about naming :)
>
> The above issue is once again a manifestation of the fact that Tuskar
> UI, despite its name, is not a UI for Tuskar, it is UI for a bit more
> services. If this becomes a greater problem, or if we want a top-notch
> CLI experience despite reimplementing bits that can be already done
> (just not in a super-friendly way), we could start thinking about
> building something like OpenStackClient CLI [2], but directed
> specifically at Undercloud/Tuskar needs and using undercloud naming.
>
> Another option would be to get Tuskar UI a bit closer back to the fact
> that Undercloud is OpenStack too, and keep the name "Flavors" instead of
> changing it to "Node Profiles". I wonder if that would be unwelcome to
> the Tuskar UI UX, though.
>
>
> Jirka
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-December/021919.html
>
> [2] https://wiki.openstack.org/wiki/OpenStackClient
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>