Re: CIM Provider HOWTO Document
by Stephen Gallagher
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/04/2013 05:15 PM, John Dennis wrote:
> When I started development of the realmd CIM provider I was told I
> was being a guinea pig. Take a developer who knows nothing about
> CIM or OpenLMI and see what issues a novice might encounter when
> asked to write a CIM provider. Then use that experience to write
> up documentation to pave the way for other developers to follow.
>
> When I first started a few months ago the material on the OpenLMI
> wiki was sparse. I see that it has since been enhanced.
>
> Attached is a 24 page PDF. It is what I would have liked to have
> started with as a developer.
>
> The content is written in pandoc format, a universal format that
> can be formatted into HTML, PDF, mediawiki, reStructuredText, and
> many other document formats. As such this content can be put up on
> the web easily. I'm distributing this initial draft as a PDF
> because in my opinion the PDF formatting yields the most readable
> presentation. The document contains many clickable links to other
> material.
>
> Those of you in the OpenLMI group will no doubt have corrections
> and suggestions on the technical content which I welcome, I'm sure
> as a neophyte I've made some errors along the way. Others may want
> to add their own suggestions and comments.
>
> It's been an interesting ride. I hope this serves as a good
> foundation to build upon.
>
> John
>
Thank you, John. You've obviously put a lot of time and effort into
this document, and it shows. I hope you will forgive my nitpicks :)
Here are my first thoughts (I haven't read through it all yet).
Issues I see:
In the "WBEM Components" on page three, you describe "only one
protocol is in wide use, CIM Operations over HTTP". This is not
actually strictly true. There are a number of companies (Dell,
Microsoft) using the WS-MAN protocol instead. We're currently
investigating whether it makes sense for the OpenLMI project to offer
both protocols, but at the moment we've chosen WBEM because we believe
it to be technically superior due to its introspection capabilities.
First line of page 6: s/breath/breadth/
Last paragraph of page 6:
s/what KonkretCMPI gives to is is incomplete/what KonkretCMPI give you
is incomplete/
When introducing the two CIMOMs, it might be useful to note their
respective licenses (MIT for OpenPegasus and MPL for SFCB). This can
be a deciding factor in selecting which one to use or which license to
use for your own provider.
Formatting:
Using boldface fonts to denote high-importance content isn't clear
enough, since it's too close to the section header appearance. Perhaps
italics (or boldfaced italics) would be more readable? Case in point,
under "CIM Schema and MOF Syntax", the boldfaced note at the end looks
exactly like the header of the "Models and Profiles" section.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlFeyh8ACgkQeiVVYja6o6OkrQCcDYSOq7upd84ykeZIt10cRWIc
+igAnikYqKXBEXoClJRfX1dDCrJNQPgz
=/Tl6
-----END PGP SIGNATURE-----
11 years, 1 month
Some thoughts on LMIShell and scripton development
by Stephen Gallagher
-----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-----
11 years, 1 month
Indication manager design draft
by Roman Rakus
I would like to inform you that I've started creating Indication Manager.
The main ideas are written on my fedorapeople page [1]. Please take a
look, read and think about it and let me (a list) know what do you think
about it.
It's just "dump of mind", direction, design I chosen. There are still
missing pieces to be coded.
RR
[1] http://rrakus.fedorapeople.org/im/
11 years, 1 month
Storage overwrite/delete policy
by Jan Safranek
Hi,
I'm polishing my storage provider and I want to discuss policy when the
provider deletes or overwrites something.
I propose:
A block device can *not* be deleted or overwritten (added to MD RAID,
formatted with a filesystem, formatted as physical volume etc) if and
only if:
- There is a filesystem on the device and the filesystem is mounted.
- Or, any other block device depends on it (Blivet knows this):
- The device is member of a running MD RAID.
- The device is member of a running volume groups.
- The device is formatted as LUKS and the LUKS is opened.
- (I haven't tested, but I suppose) The device is path of running
multipath device.
In these cases OpenLMI storage provider returns an exception
(ERR_FAILED), with description that 'Device %s is still used.'
All other devices can be deleted or overwritten. That includes (but is
not limited to):
- Device with unknown filesystem.
- Device with MD RAID metadata, which is not running.
- Device with physical volume metadata, but not part of any running VG.
- Device with a filesystem, which is not mounted.
Does this make sense?
Jan
11 years, 1 month
