Open Stack

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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev