Some thoughts on LMIShell and scripton development

Peter Hatina phatina at redhat.com
Wed Apr 3 06:55:28 UTC 2013


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

On 04/01/2013 09:16 PM, Stephen Gallagher wrote:
> I've been thinking about how we should go about developing and 
> deploying scriptons for use with LMIShell. We definitely want to 
> define a set of coding standards and best practices early on, 
> especially if we want this community to grow. Here are a few of my 
> thoughts (more to come eventually):
> 
> == Coding Style ==
> 
> First off, I think we probably want to formalize a coding style 
> guideline. Given that the scriptons are going to be written in
> Python, I think we'd probably be best off by standardizing around
> PEP 8[1]. It's well established and there are plenty of tools
> around that will provide validation of the style guideline (and in
> some cases can automatically correct it).

Agree.

> 
> Beyond that, we need to establish a set of best practices and a
> decent division between the components that are shipped as part of 
> OpenLMI[-shell] and the scriptons themselves.
> 
> 
> == Architecture ==
> 
> In my view, we want to make certain that LMIShell provides a number
> of useful functions to simplify the creation of the scriptons. 
> Specifically, we will want to offer library routines for the
> following (non-exclusive) functionality: * Binding to the CIMOM
> (using WBEM) * Gathering and maintaining credentials * Establishing
> a session (see below) * Constructing and transmitting requests *
> Receiving both synchronous and asynchronous replies
> 
> The scriptons should consume these library routines wherever
> possible and therefore should be comprised predominately of the
> business logic of their functionality. Ideally, they should each be
> effectively a single Python function, performing one "task" (not
> necessarily a one-to-one correspondence with a CIM request) with a
> simplified public interface. For example, a scripton might be
> written to "enlarge an ext4 partition by N megabytes" that will
> extend an LVM partition, then the ext4 partition.

OK.

> 
> 
> == Design considerations ==
> 
> === Sessions ===
> 
> The OpenLMI connection and authentication routines should validate
> the connection to the CIMOM. The authentication might be verified
> by having us perform a simple, trivial request to prove that access
> is fully available. These routines should result in the creation of
> a "session" object that should be effectively opaque (insofar as
> Python objects are never opaque). Each scripton should accept the
> session as part of their input and pass it, unmodified, to the
> library routine for transmitting requests and registering for
> responses. Under the hood, this object should be maintaining
> whatever credentials are needed to perform the requests. The goal
> here is to avoid any situation where a scripton would need to be
> aware of or prompting for the user's actual credentials. Hopefully,
> this can be designed in such a way as to be invisible to the
> scripton writer whether the user is using HTTP-BASIC, X.509 or
> GSSAPI credentials.
> 
> One thing we *must* avoid is singleton sessions. It must always be 
> possible for a single script to instantiate multiple session
> objects (for example, if we're queuing up requests to thirty
> machines, they will need thirty session objects). As such, we
> cannot rely on any global values; each session object will need to
> maintain a complete representation of the CIMOM and credentials
> necessary to continue that session.

Will consider this. Currently, there are kind-of session objects used
<- the connection objects, where each of them holds necessary
credentials, etc.

> 
> === Scripton design ===
> 
> Scriptons should follow standard Python recommendations for return 
> values and exceptions. We should make an attempt to properly
> handle any expected exceptions (such as network errors) at all
> levels (both in scriptons and OpenLMI)

Wrt shell, I was not 100% sure, if to use exceptions or not. I know
python uses them as often as possible, but from the user point of
view, I wanted to avoid them (they can be turned on in the running
shell), because of the stack trace etc, when an error occurs (are the
lmishell users programmers?). Maybe I could drop the code, which
"traps" the exceptions and packs them into classic C-return values, if
we are OK with that.

> 
> 
> === Script design ===
> 
> We should provide some template examples on how to consume
> scriptons as part of a larger Python script. Specifically, we will
> want to demonstrate the use of each of the library functions and
> calling into the scriptons. This is probably more of a
> documentation effort than anything else.

OK.

> 
> 
> [1] http://www.python.org/dev/peps/pep-0008/ 
> _______________________________________________ openlmi-devel
> mailing list openlmi-devel at lists.fedorahosted.org 
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
> 

- -- 
Peter Hatina
EMEA ENG-Base Operating Systems
Red Hat Czech, Brno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRW9JgAAoJELOyt3XzKCKpjjsIAMJ/sMpfWNXd7s+WydycqXwr
Wualwx4j6dmhEK/E0hqFIdm1yIp5a0BWXQumDhrL4PU8GM7klyDI5p4bh+xu4RHe
bxcfl62LUvtuyecz9WQQ4gEgZPk2S0hO8po9rDHu8MAqlzevQuNyuDIboEL687oJ
PDAfFKkXSXde5Va/0JRZicak2zSG5UeK7qzr6H3mxt+IFRx0bpJNwhhdsLxVfLt6
Y+oL7BWjk2MmQWqt0Lct64PVcYz3gbp3MGDO2SzkThzY98q3IFA/+h8oo6qs6kZ2
ZcIfNMa3WDeMAlbXMtWCzG2OM+QIrXOsoLoASKBGvFXJH0ify+3ey90Zp65m+UM=
=LHPS
-----END PGP SIGNATURE-----


More information about the openlmi-devel mailing list