On 2014/27/03 19:04, Jiří Stránský wrote:
On 27.3.2014 18:21, Dougal Matthews wrote:
[snip]
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
On 27/03/14 18:11, Jay Dobies wrote:
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
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
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
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
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
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.
