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.
+1
I've always liked the idea of separating out the bindings from the CLI
itself.
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
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
