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