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


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.

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