2:16 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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).
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.
== 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.
=== 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)
=== 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.
[1] http://www.python.org/dev/peps/pep-0008/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFZ3QQACgkQeiVVYja6o6MP/gCgq2rHhiQV1H6ibyNX8zfqMhM3
AJcAoKZf7tN9rfEpIOJT3Ub0OBIEGH0j
=3oyz
-----END PGP SIGNATURE-----