I think if we will use Openstack CLI, it has to be something like this https://github.com/dtroyer/python-oscplugin.
Otherwise we are not Openstack on Openstack.

Btw. abstracting it all to one big CLI will be just more confusing when people will debug issues. So it would
have to be done very good.

E.g calling 'openstack-client net-create' fails.
Where do you find error log?
Are you using nova-networking or Neutron?

Calli 'neutron net-create' and you just know.

Btw. who would actually hire a sysadmin that will start to use CLI and have no idea what is he doing? They need to know what each service do, how to correctly
use them and how do debug it when something is wrong.

For flavors just use flavors, we call them flavors in code too. It has just nicer face in UI.

Kind regards,

On 02/26/2014 02:34 PM, Jiří Stránský wrote:

i went through the CLI way of deploying overcloud, so if you're interested what's the workflow, here it is:


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.


[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 mailing list

Reply via email to