RFC Feature Planning: User Groups

Mo Morsi mmorsi at redhat.com
Thu Apr 5 13:11:04 UTC 2012


>>> * This is probably out of scope, but I would hope we will include a
>>>  task(s) to make whatever controller changes are needed also provide
>>>  an api?
>>>
>> Yes, we should define the API here. We'll need API for
>> creating/removing/altering groups, and (for local groups)
>> adding/removing group members.
>>
>> General question here -- going forward, are "build out API" tasks
>> going to be done across the board at some point? Also, do we assume
>> that _every_ new feature we add from now on includes implementing the
>> basic APIs for the main objects associated with that feature?
>>
>
> I would like for us to assume that any new feature that will get UI
> (and perhaps even some that dont) should have api built at the same
> time.  If that means we need to add separate tasks and get more people
> working on the feature together, I think that is ok.  And yes, I
> believe the intent is to really start to focus on building out api for
> everything we already have, the providers/accounts is just the first
> example.
>

+1. Also would like to see instance support in the API at somepoint,
added a feature placeholder for this [1] but the proposed features list
is getting somewhat long [2] so no worries if that gets pushed back
(maybe we can rope some of the students proposing to work on Aeolus for
the GSoC into hacking on this bit or other features that get pushed back)

  -Mo

[1] https://www.aeolusproject.org/redmine/issues/3110
[2] https://www.aeolusproject.org/redmine/projects/aeolus/versions/146





More information about the aeolus-devel mailing list