RFC: Script development

Stephen Gallagher sgallagh at redhat.com
Wed Jun 12 10:08:25 UTC 2013



On Jun 12, 2013, at 5:23 AM, Roman Rakus <rrakus at redhat.com> wrote:

> 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)

No, I think the idea here is that we would have you establish the namespace connection once and store that as a global variable in the lmishell. After that, unless you specifically pointed at a different namespace, we would just use that first one under the hood. We can't put this in a config file easily, because it implies an active connection and we don't want to be reconnecting constantly.


>> 
>> - 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?


The ideal case would be for the cmdline tools to cover any aspect of the script on that is usefully exposed to the use, but this will not always everything that the script on can provide. I suggest that we just use our best judgement here on which pieces to turn into cmdline tools. We can always extend it later if we need to.


>> -> 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.

I think that since the stated goal of OpenLMI is to provide consistency between configuration tools where none previously existed, we should build the cleanup version first and leave the "mimic" approach as a nice-to-have RFE for the future. However, I would like Russ to comment on this.


>> 
>> - 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?


Let's try to keep the lmishell "core" as lean as possible and do most real work in the scriptons. My vision here is that lmishell should essentially just be a better wbemcli (plus scripton enablers), but when you add a scripton atop it, it becomes something usable by a human being. That's my opinion, of course. I am open to counter-arguments.


>> 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.
> 

Right now, our plan is to recommend that the end-user just builds a loop through machines in the outer script that calls the scriptons. As Jan mentioned, the more we tried to solve that directly in the scriptons, the more corner cases we had to fight through.


> RR
>> 
>> 
>> 
>> _______________________________________________
>> openlmi-devel mailing list
>> openlmi-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
> 
> _______________________________________________
> 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