Open Stack

On 04/05/16 20:54, "Sean Dague" <sean at dague.net> wrote:

>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

As we implement nested projects, the ‘admin’ activities become much more
difficult to define. Typical use case would be if I was the project administrator
for the ATLAS project. I would want to be able to define new projects such
as “ATLAS Higgs” with appropriate membership and quota within the limits
defined by the cloud administrator.

My understanding from this transition is that the majority of the project
commands would be ‘standard’, and therefore OSC support is needed if
the universal client CLI goal is to be achieved.

Tim
>
>-- 
>Sean Dague
>http://dague.net
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev