> On Nov 10, 2013, at 3:47 PM, Paul Belanger <paul.belan...@polybeacon.com>
>> On 13-11-10 12:36 PM, Jay Pipes wrote:
>>> On 11/10/2013 10:15 AM, Noorul Islam K M wrote:
>>> Hello all,
>>> I registered a new blueprint  for command line client interface for
>>> Solum. We need to decide whether we should have a separate repository
>>> for this or go with new unified CLI framework . Since Solum is not
>>> part of OpenStack I think it is not the right time to go with the
>>> unified CLI.
>> I think a separate repository (python-solumclient) is appropriate.
>> There are two main camps of client tool programming: using the cliff
>> library  and using the framework that was originally used for the
>> Rackspace Cloud Servers CLI tool and library.
>> Example of the cliff style is python-neutronclient . Example of the
>> other style is the current python-novaclient .
>> I actually would love to see the Solum client take the best of both of
>> the styles and create a client library that uses the cliff library for
>> the underlying CLI plumbing and use the object-oriented style of
>> python-novaclient that returns Resource objects instead of raw dicts
>> like python-neutronclient does...
>>  https://cliff.readthedocs.org/en/latest/
>>  https://github.com/openstack/python-neutronclient
>>  https://github.com/openstack/python-novaclient
> +1 to cliff. I've used cliff a few times now for some CLI clients and it
> works very well.
Even though it'll be a long time (maybe never) before Solum is a core project,
it'd be good to track the CLI work going on in the common client . The
session at the design summit  definitely conveyed a broad agreement on this
direction (ie common client is mostly inevitable), so being cognizant of the
plugin pattern they have going is smart. We could potentially ship an isolated
common client (ie based on that code) that used only a Solum plugin, so in the
future we would have the option to switch to being integrated.
OpenStack-dev mailing list