Open Stack

> On Nov 10, 2013, at 11:41 PM, Noorul Islam K M <noorul at noorul.com> wrote:
> 
> Clayton Coleman <ccoleman at redhat.com> writes:
> 
>>>> On Nov 10, 2013, at 3:47 PM, Paul Belanger <paul.belanger at polybeacon.com> wrote:
>>>> 
>>>>> 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 [1] 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 [2]. 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 [1] 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 [2]. Example of the
>>>> other style is the current python-novaclient [3].
>>>> 
>>>> 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...
>>>> 
>>>> Best,
>>>> -jay
>>>> 
>>>> [1] https://cliff.readthedocs.org/en/latest/
>>>> [2] https://github.com/openstack/python-neutronclient
>>>> [3] 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 [1].  The session at the design summit [2] 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.
> 
> Isn't that going to be painful to sync changes in CLI work into this
> separate repository often? I think we have to keep doing that because
> there will be bug fixes and other enhancements. 

The implication I heard from the session is the command infrastructure and client code have or will have a well defined interface from the framework, although I haven't looked through current state enough to say that's totally true today.  If that interface is in place we certainly would be better isolated from upstream.

I guess it depends where we want to spend our focus as well - do we write something that in the long run we'd end up porting, or benefit from the work the common client is doing (doc, common patterns, keystone auth work with x509 and potentially Kerberos, bash completion, etc) as well as help them out.

It might be too early to draft.... but if the stuff we'd get for free is more cost than staying up to date with changes, I'd say that would be a good argument to pitch in.