RFC: Script development

Roman Rakus rrakus at redhat.com
Wed Jun 12 09:23:11 UTC 2013


Hi,
On 06/11/2013 10:52 PM, Jan Safranek wrote:
> Hi,
>
> 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
agreed
>
> (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).
>
> - 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.
agreed
>
> - 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.
agreed
>
> (we were thinking about python functions just scheduling multiple
> actions and do stuff in parallel massively, but we quickly got into lot
> of corner cases)
>
> - each high-level function takes a LmiNamespace parameter, which
> specifies the WBEM connection + the namespace on which it operates
> -> i.e. applications/other scripts can run our functions on multiple
> connections
> -> if the LmiNamespace is not provided by caller, some 'global' one will
> be used (so users just connect once and this connection is then used for
> all high-level functions)
-> global configuration file(s)
>
> - we should probably split these high-level function to several modules
> by functionality, i.e. have lmi.networking and lmi.storage.vg,
> lmi.storage.lv etc.
agreed
>
> - it should be easy to build command-line versions for these high-level
> functions
So, in these "devel scripts" we will have "all functionality"? And only 
some higher level (cmdline tools) will just cover common cases?
The main question here is if we really need to encapsulate everything 
or, if not everything, what to provide?
> -> it is not clear if we should mimic existing cmdline tools (mdadm,
> vgcreate, ip, ...) or make some cleanup (so creation of MD raid looks
> the same like creation of a VG)
I'm not sure here, but alias (or something similar) could help here.
>
> - we should introduce some 'lmi' metacommand, which would wrap these
> command line tools, like 'lmi vgcreate mygroup /dev/sda1 /dev/sdb1' and
> 'lmi ip addr show'. It's quite similar to fedpkg or koji command line
> utilities.
>
> - 'lmi' metacommand could also have a shell:
> $ lmi shell
>> vgcreate mygroup /dev/sda1 /dev/sdb1
>> ip addr show
>
> I tried to create a simple module for volume group management. I ran
> into several issues with lmishell (see trac tickets), attached you can
> find first proposal. It's quite crude and misses several important
> aspects like proper logging and error handling.
>
ok... on which "version" of lmishell we will build upon? We can try to 
start creating scripts, report issues and on some point mark lmishell 
and scripts as "good enough". Any other thoughts?
> Please look at it and let us know what you think. It is just a proposal,
> we can change it in any way.
>
> Once we agree on the concept, we must also define strict documentation
> and logging standards so all functions and scripts are nicely documented
> and all of them provide the same user experience.
>
> Jan
>
> P.S.: note that I'm out of office for next week and with sporadic email
> access this week.
I'm missing one piece - management of more systems at once. But I think 
it's on the TODO list of lmishell. So it could be easy to achieve this.

RR
>
>
>
> _______________________________________________
> openlmi-devel mailing list
> openlmi-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
>



More information about the openlmi-devel mailing list