Hello,
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,
Ladislav
On 02/26/2014 02:34 PM, Jiří Stránský wrote:
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
_______________________________________________
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
