Open Stack

On 04/05/16 22:53, Jay Pipes wrote:
> On 05/04/2016 01:08 PM, Chris Dent wrote:
>>
>> The plans for generic resource pools[1] include a suite of new
>> commands for creating and updating resource pools. In today's Nova
>> API meeting[2] and afterwards in #openstack-nova[3] we discussed two
>> issues:
>>
>> * Since the placement API associated with resource pools is eventually
>>    going to be hoisted out of nova it will be developed in a decoupled
>>    fashion within the nova tree. It makes sense to also hoist the client
>>    libraries in the same fashion. The canonical plan for CLIs is to
>>    plug in to OSC.
>>
>> * There's some confusion on whether commands that are destined for
>>    admins and services but not end users are "supposed" to be in OSC.
>>
>> Since then the spec has been updated to reflect using OSC but the
>> question of whether this is in fact the right place for this style
>> of commands remains open. Not just for this situation, but
>> generally.
>>
>> Is there an official word on this? If not, should we make one?
>
> My position is that if it's an HTTP API (as opposed to something like 
> a sqlalchemy-migrate sync command) then it belongs in a client that 
> speaks the OpenStack HTTP APIs. That is OSC as far as I can tell. I 
> don't see a difference between "admin" commands and "standard" commands.
>

There is a very blurry line between "admin" and "standard" commands in 
most of the cases. (In shade, is already split between operatorcloud.py 
and openstackcloud.py, and for any new capability to include, the first 
discussion, always, is where to put it) Splitting it, will only 
frustrate operators and users trying to remember which function is 
included in each command (and knowing Murphy's law, they will always 
choose the wrong one). So, please, just one command to rule them all.

Ghe Rivero