Open Stack

On 05/04/2016 02:16 PM, Dean Troyer wrote:
> On Wed, May 4, 2016 at 12:08 PM, Chris Dent <cdent+os at anticdent.org
> <mailto:cdent+os at anticdent.org>> wrote:
> 
>     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.
> 
> 
> This came up again last week, and there is still no real consensus as to
> whether admin-only stuff should be included in the repo or kept in
> plugins. The things already in the OSC repo are likely to stay for the
> forseeable future, new things could go either way.
> 
> If you are planning a separate client/lib, it would make sense to do the
> OSC plugin as part of that lib.  That is also a chance to get a really
> clean Python API that doesn't have the cruft of novaclient

I think that in the case of the new "placement" API we really want to
give it a fresh start. It will be a dedicated endpoint from day one, and
the CLI interaction with it should definitely live outside of
novaclient. First, because there is no need to take a lot of the gorp
from novaclient forward. Second, because we want it really clear from
day one that this effort is going to split from Nova, and you can use
this thing even without Nova.

This will, at some level, be pretty core infrastructure. Nova, Neutron,
Cinder (at the least, I'm sure more will over time) will need to talk to
it programatically, and administrators may need to do some hand tuning
of resource pools to express things that are not yet automatically
discovered and advertised (or that never really make sense to be).

Given these constraints it was as much of an ask as anything else. Can
OSC handle this? Should it handle it from a best practices perspective?
How are commands exposed / hidden based on user permissions? The fact
that we're going to need a service library mean that a dedicated admin
API might be appropriate?

	-Sean

-- 
Sean Dague
http://dague.net