Report from Fourth Annual Management Developers Conference

The fourth Management Developers Conference (mandevcon) took place November 17 - 20 2008, in Santa Clara, California.

This is the annual get together of people involved and interested in systems management technologies and standards as defined by the Distributed Management Task Force (DMTF).

The DMTF is an industry organization defining systems management standards such as the Common Information Model (CIM) or Web Services for Management (WS-Management).

For my employer, these standards play an important role as they're part of the Novell/Microsoft technical collaboration agreement about interoperable systems management.

Compared to last year, attendance to the conference was very low. I guess only about a third of last years attendance numbers were reached. This decline was mostly attributed to slashed travel budgets due to the tough economy. However, hallway conversations also hinted towards lack of scope of the conference, trying to be everything for everyone. A split into research, development and deployment topics is probably needed.

Presentations during the three days of the conference are divided into three parallel tracks. These were

• the DMTF industry initiatives (http://www.dmtf.org/initiatives)
  like
  • SMI (storage management)
  • CDM (diagnostic)
  • CMDB (configuration database)
  • Virtualization
  • SMASH (server hardware)
  • DASH (desktop hardware)
• CIM core technology
• Web Services for Management
• Developers

The full conference schedule can be obtained from here.
Sadly, the presentation slides (mostly PDF) are only available to attendees (authorization needed).

Being busy with my own slides, I wasn't able to attend as many presentations as I wanted. But I still made it to the following presentations of the first day:

Python CIM providers

Writing CIM instrumentation has a long history of being complicated and needing C or C++. Bart Whiteley of Novell presented pywbem, showing how to write CIM providers in a modern scripting language. Pywbem also comes with a provider generator, spitting out a Python skeleton provider from the definition of its CIM classes.

Multi-Tenant CIMOM, Fact or Fiction

There are a couple of CIM object managers (CIMOMs) available, mostly as open-source. However, CIM providers are mostly CIMOM-specific and can't be easily ported. With the Common Manageablity Programming Interface (CMPI), a standard ABI for CIM providers is established. Still configuration information required to install a provider is different from CIMOM to CIMOM.

This presentation showed typical obstacles in writing portable providers and gave rules and recommendations to make a provider cimom-agnostic.

cmpi-bindings - Compiler Free Provider Development

This was the first of my own presentations. Cmpi-bindings serves a similar purpose like pywbem, freeing CIM provider developers from the need for C or C++.

cmpi-bindings uses SWIG to generate bindings between the Common Manageablity Programming Interface (CMPI, the ABI between a CIMOM and a CIM provider) and a scripting language. Currently supported are Python, Ruby and Perl. Any other SWIG supported language can be added fairly easily. cmpi-bindings use SWIG in an innovative way, allowing to call into the scripting language from the CIMOM. This effectively reverses the typical flow of control for SWIG, which is calling a C or C++ library from a scripting language.

Testing with PyWBEM

Automated testing of CIM providers is often neglegted and developers use plain CIM browsers to explore their code.

Tim Potter showed various ways for testing providers with the help of Python and pywbem. Most interesting was learning about Twisted, a Python networking framework for asynchronous programming. This stuff makes your brain hurt and the O'Reilly book title illustration is worth a thousand words ;-)

---

On day 2, I had the opportunity to attend Microsofts 'Strategic Architect Forum' in San Francisco. So I skipped the mandevcon presentations for that day. I'll blog later about the Microsoft conference.

---

The last day had a complete track on WS-Management.
It started with a generic introduction by Josh Cohen from Microsoft. Josh is leading the WS-Management work group within the DMTF and the driving force behind Microsofts adaption of an open standard for systems management. Too bad his presentation isn't available online.

Openwsman swig bindings

Anas Nashif, of AutoYaST fame, showed the Openwsman swig bindings Openwsman is an open source implementation of the WS-Management protocol, used e.g. by Microsoft Windows for remote systems management.

These bindings allow for easy ws-management client programming using one's favorite programming language. Fully supported currently are Python, Ruby and Java (yuck!).

Scripting openwsman server plugins

WS-Managment is a generic protocol for resource management. Each resource is identified by a universal resource identifier (URI), which onsists of a namespace and a resource part. The openwsman server maps namespaces to plugins and lets the plugin handle the specific resource implementation.

Openwsman includes default plugins for the generic Identify operation and for CIM operations (WS-CIM). Writing plugins in C is easy, using a scripting language makes it even easier.

My presentation shows how the problem was approached and describes the implementation. It is in an alpha state currently and needs some more work to become fully functional. This will also require some changes in the openwsman plugin API to fully support plugins.
The code is part of the openwsman svn repository and available here.

ActiveWSMAN

One thing that bothers me when coding against the openwsman client API is the amount of protocol knowledge needed. Doing a simple enumeration call requires one to know about the enumerate, pull and release protocol functions. Not to mention keeping track of the context.

Having enjoyed the ActiveRecord pattern as implemented in Ruby On Rails, I collected some thoughts around using this for WS-Management client programming.

The presentation shows a concept on how to make a developers life much easier. It focuses on resources and their semantics, completely hiding the internals of the ws-management protocol.

A proof-of-concept implementation based on ActiveRecord exists and I itend to complete it in the next couple of weeks.

MDC presentations available

Anas asked me to make my Management Developers Conference presentations available, so here they are.

Web Service Management On Rails

In the first one, WS-Management On Rails, covers the beauty of accessing WS-Management and WS-CIM functionality through Ruby. The code follows the DMTF Technologies Diagram and consits of

• rcim for the CIM Infrastructure layer
This implements the CIM metamodel of classes, properties and qualifiers.
• mofgen to generate WS-CIM bindings
Mofgen is an extension to the Cimple MOF parser. It generates Openwsman client bindings for CIM classes from the class description contained within a MOF file.
• rwscim for the CIM Schema class hierachy
This puts a wrapper around the bindings generated by mofgen, makes them available as a single Ruby module and ensures the correct class hierachy.

And here is a git repository containing a Rails application showing all this in action.

Web Service Management Application Enablement

Web Service Management Application Enablement is about using WS-Management as a transport layer for remote application access. Instead of implementing a separate daemon, protocol and data model, riding the WS-Management horse gives all of this almost for free. And its more secure. The dynamic plugin model provided on the Openwsman server side makes this particularly easy. The presentation shows how to plan and implement such a plugin and gives two examples. openwsman-yast for a simple, RPC-type approach and openwsman-hal which follows the WS-Management resource model.

openwsman-yast now returns proper datatypes

After five days of hacking last week, a final itch was left which needed scratching. The YaST openwsman plugin only passed strings back and forth, losing all the type information present in the YCP result value. So I added some code to convert basic YCP types to XML (in the plugin) and from XML to Ruby (on the client side). Now the result of a web service call to YaST can be processed directly in Ruby. Here's a code example showing the contents of /proc/modules on a remote machine.

require 'rwsman'
require 'yast'
client = WsMan::Client.new( 'http', 'client.internet.org', 8889, '/wsman', 'user', 'password')
options = WsMan::ClientOption.new
schema = YaST::SCHEMA
uri = schema + "/YCP"
options.property_add( "ycp", "{ return SCR::Read( .proc.modules ); }" )
result = client.invoke( uri, "eval", options )
modhash = YaST.decode_result( result ) # hash of { modulename => { size=>1234, used=>3 } }

Supported are void, bool, integer, float, string, symbol, path, term, list, and map -- should be sufficient for most of YaST. The YaST class is here. You need at least version 1.1.0 of openwsman and openwsman-yast, both available on the openSUSE build service. And, btw, source code for openwsman-yast is now hosted on svn.opensuse.org

Remote management with Rails

The Rails demo for remote systems management with WS-Man is available at the openwsman web site.
Just follow the install and configure instructions. In short you need

• openwsman
  An open source implementation of the ws-management standard.
• rwsman
  Ruby bindings for openwsman client operations.
• Ruby On Rails
  Web development that doesn't hurt
• Railsapp
  Rails demo application for rwsman

Once everything is properly installed, start the Rails web server with ruby script/server. Now point your browser to http://localhost:3000 and you'll see the startup page. Click on the text, then click on Discover and the Discovery page will appear.

Look closely at the Actions line for each host and you'll notice the YaST action for the openSUSE client. This client has my openwsman-yast plugin installed.
The demo application allows to start and stop the desktop (the xdm service to be precise) and to switch the desktop environment between KDE and GNOME. YaST operations

Doc has videotaped a demo, you can find it in the idea.opensuse.org blog.

YaST as a WebService

Thanks to openwsman and openSUSE hack week, Linux systems with YaST installed can now be remotely controlled via a WebService.

My idea is now available as a package in the openSUSE build service.

Today I itend to use the openwsman ruby bindings and its Rails demo application to show true remote management.

Stay tuned ...