RFC: Script development

Jan Safranek jsafrane at redhat.com
Mon Jul 1 07:18:33 UTC 2013


On 06/12/2013 12:20 PM, Jan Synacek wrote:
> On 06/11/2013 10:52 PM, Jan Safranek wrote:
>> Hi,
> 
> Hello!
> 
>>
>> I've been talking to Stephen Gallagher how to proceed with client script
>> development in lmishell. The goal is to provide high-level functionality
>> to manage remote systems without complete knowledge of the CIM API.
>>
>> We agreed that:
>>
>> - we should provide python modules with high-level functions
>>
>> (we were thinking about nice classes, e.g. VolumeGroup with methods to
>> extend/destroy/examine a volume group, but it would end up in
>> duplicating the API we already have. We also assume that our users are
>> not familiar with OOP).
> 
> Define "our users". Are they admins that will use the scriptons from python
> scripts? If yes, I think that degrading the CIM API from OOP to pure procedural
> just doesn't sound right. Or maybe I'm just misunderstanding something here.

The CIM API will still be object-oriented, we won't hide _LmiInstance,
used in lmishell to wrap CIM objects. However, we will offer functions
to work with them (vg_create) instead of class (VG.create()).

>> - these python functions try to hide the object model - we assume that
>> administrators won't remember association names and won't use e.g.
>> vg.associators(AssocClass="LMI_VGAssociatedComponentExtent") to get list
>> of physical volumes of a vg. We want nice vg_get_pvs(vg) function. We
>> will expose CIM classes and properties though.
>>
>> - these python functions are synchronous, i.e. they do stuff and return
>> once the stuff is finished. They can do stuff in parallel inside (e.g.
>> format multiple devices simultaneously) but from outside perspective,
>> the stuff is completed once the function returns.
>
> What about leaving an option for functions that are asynchronous to run
> asynchronously? Or create both async and sync version of such functions.
> Because, again, forcing something that can be run asynchronously into a
> synchronous mode is degrading what we already have, needlessly. IMO we shouldn't
> make things more simple than simple.

This has already been agreed on with Peter Hatina. All async methods
will have synchronous variant, while the async is still available.


Jan


More information about the openlmi-devel mailing list