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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
