On 27.3.2014 18:21, Dougal Matthews wrote:
On 27/03/14 15:56, Jaromir Coufal wrote:
Hi OpenStackers,
User interface which is managing the OpenStack Infrastructure is
currently named Tuskar-UI because of historical reasons. Tuskar itself
is a small service, which is giving logic into generating and managing
Heat templates and helps user to model and manage his deployment. The
user interface, which is the subject of this call, is based on TripleO
approach and resembles OpenStack Dashboard (Horizon) with the way of how
it consumes other services. The UI is consuming not just Tuskar API, but
also Ironic (nova-baremetal), Nova (flavors), Ceilometer, etc in order
to design, deploy, manage and monitor your OpenStack deployments.
Because of this I find the name Tuskar-UI improper (it's more closer to
say TripleO-UI) and I would like the community to help to find better
name for it. After brainstorming, we can start voting on the final
project's name.
https://etherpad.openstack.org/p/openstack-management-ui-names
Thanks for starting this.
As a side, but related note, I think we should rename the Tuskar client
to whatever name the Tuskar UI gets called. The client will eventually
have feature parity with the UI and thus will have the same naming
issues if it is to remain the "tuskarclient"
Dougal
It might be good to do a similar thing as Keystone does. We could keep
python-tuskarclient focused only on Python bindings for Tuskar (but keep
whatever CLI we already implemented there, for backwards compatibility),
and implement CLI as a plugin to OpenStackClient. E.g. when you want to
access Keystone v3 API features (e.g. domains resource), then
python-keystoneclient provides only Python bindings, it no longer
provides CLI.
I think this is a nice approach because it allows the python-*client to
stay thin for including within Python apps, and there's a common
pluggable CLI for all projects (one top level command for the user). At
the same time it would solve our naming problems (tuskarclient would
stay, because it would be focused on Tuskar only) and we could reuse the
already implemented other OpenStackClient plugins for anything on
undercloud.
We previously raised that OpenStackClient has more plugins (subcommands)
that we need on undercloud and that could confuse users, but i'd say it
might not be as troublesome to justify avoiding the OpenStackClient way.
(Even if we decide that this is a big problem after all and OSC plugin
is not enough, we should still probably aim for separating TripleO CLI
and Tuskarclient in the future.)
Jirka
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
