[Freeipa-devel] Bulk IPA commands

[Rob Crittenden]

Adam Young wrote:
> On 10/22/2010 04:08 PM, Rob Crittenden wrote:
>> Adam Young wrote:
>>> I did a quick spike into what it would take to implement my idea and got
>>> this far (done in internal.py)
>>>
>>>
>>> class bulk(Command):
>>>
>>> takes_args = (
>>> List('methods?',
>>> doc=_('Nested Methods to execute'),
>>> ),
>>> )
>>>
>>> has_output = output.standard_entry
>>> def execute(self, *args, **options):
>>> results=dict();
>>> for arg in args:
>>> for method in arg:
>>> results[method]=unicode("OK")
>>>
>>> return dict(result=results, value=unicode("Something"))
>>>
>>> api.register(bulk)
>>>
>>>
>>>
>>>
>>> And tested it using:
>>>
>>>
>>> [ayoung at ipa ~]$ curl -H "Content-Type:application/json" -H
>>> "Accept:applicaton/json" -H "Accept-Language:en" --negotiate -u :
>>> --cacert /etc/ipa/ca.crt -d
>>> '{"method":"bulk","params":[[],{"methods":"1,2" }],"id":6}' -X POST
>>> http://localhost:8888/ipa/json
>>> {
>>> "error": null,
>>> "id": 6,
>>> "result": {
>>> "result": {
>>> "1": "OK",
>>> "2": "OK"
>>> },
>>> "summary": null,
>>> "value": "Something"
>>> }
>>> }
>>>
>>>
>>> I don't think the List type is going to work for this. We need, I think,
>>> a Dict type here, in order to support the full JSON Parsing, we might
>>> need a true array type as well. Or, we could make separate methods for
>>> JSON and XML and make a type for each of those. Any thoughts?
>>>
>>
>> You can define your own output format, look in ipalib/Output.py. In
>> this case I think a list of a dict of results is probably the right
>> thing.
>
> Yeah, problem is input format, not output. Output I know we can do based
> on how we did the json_metadata, although based on your comment, it
> looks like we can do it in a more standard manner.

Ah, ok. I think something like:

MULTICALL: list of CALL

CALL: dict(METHODNAME, ARGS, OPTIONS)

METHODNAME: string

ARGS: list

OPTIONS: dict

ex:

[
    {'method': 'user_show',
     'args': ['admin'],
     'options': {'all': True, 'raw': True}
    },
    {'method': 'user_show',
     'args': ['kfrog'],
     'options': {'all': True, 'raw': True}
    },
]

IIRC this is pretty similar to what you first proposed.

rob

>
>
>>
>> So we have a list of results whose position maps to each method call.
>> In each position we store the name of the method call (just for
>> clarify) and the results of that call.
>>
>> It might look like this to show two separate users:
>>
>> [{'method': 'user_show', result={'result': {'dn':
>> u'uid=admin,cn=users,cn=accounts,dc=greyoak,dc=com', 'memberof_group':
>> (u'admins',), 'uid': (u'admin',), 'loginshell': (u'/bin/bash',),
>> 'homedirectory': (u'/home/admin',), 'sn': (u'Administrator',),
>> 'memberof_rolegroup': (u'replicaadmin',), 'memberof_taskgroup':
>> (u'managereplica', u'deletereplica')}, 'value': u'admin', 'summary':
>> None}},
>> {'method': 'user_show', result={'result': {'dn':
>> u'uid=kfrog,cn=users,cn=accounts,dc=greyoak,dc=com', 'memberof_group':
>> (u'ipausers',), 'uid': (u'kfrog',), 'loginshell': (u'/bin/bash',),
>> 'homedirectory': (u'/home/kfrog',), 'givenname': (u'Kermit',), 'sn':
>> (u'Frog',)}, 'value': u'kfrog', 'summary': None}}]
>>
>> You could probably even throw in *args and **options too.
>>
>> This way when you pull result[0]['result'] you have what user_show
>> would have returned for user_show admin.
>>
>> rob
>