[RFC] New provider registration process

Tomáš Smetana tsmetana at redhat.com
Mon Aug 19 10:22:22 UTC 2013


Hello,
  I'm now trying to figure out how to improve the provider registration
process to make things at least look less fragile from the user's perspective.

We're still facing problems with the providers and CIMOMs installation:  the
openlmi-* provider packages depend on a virtual require (cim-server) and it's
beyond our control which package is installed by yum to satisfy the
dependency (sblim-sfcb currently IIRC).  If this is not what the user wants
or the user decides to switch the CIMOM, install another one etc., then the
providers have to be re-registered again manually which is not an easy task
since the order of the mofs/regs is not saved anywhere and each CIMOM (and
even CIMOMs version) requires special procedure.

My plan is to store the registrations in a special CIMOM-independent database
which would enable the user to re-do the registrations at any time.  Most
notably we should be able to re-register whatever provider is installed on
the system from the CIMOMs package post-install scriptlets.

The new script should offer three actions: register, unregister and
reregister. Registration and unregistration will require the same arguments
as the current script.  I'm pretty sure there are many details and
combinations that can't be handled reasonably well.  However here's some
idea dump on how I suppose things might work:

=============================================================================
Registration

The user specifies one or more MOF files zero or one REG file. Optionally
will request the CIMOM to register for, namespace and version of the provider
for the REG file.  If the CIMOM was not explicitly requested register for all
the known CIMOMs in the database and for all the CIMOMs installed/found.
Registration should handle the update transparently. The files, version
string, CIMOM and namespace form the "registration object" which is what we
need to be able to re-assemble during re-registration.

  1 if (none of the MOFs/REG in the database yet) {
  2     registration = create new registration (id + timestamp)
  3 } else if (the known MOFs/REG belong to the same registration) {
  4     registration = the one the MOFs/REG belong to
  5     if (requested CIMOMs != CIMOMs of the existing registration)
  6         exit with error: upgrade must be valid for all the previous 
  7         registrations
  8 } else {
  9     exit with error: only one registration can be replaced
 10 }
 11 unregister the previous registration from CIMOM(s)
 12 if (error) {
 13     exit
 14 }
 15 remove the old files backups 
 16 copy the new MOFs/REG to the backup location
 17 update/insert database records (don't overwrite existing registration
    timestamps)

=============================================================================
Unregistration

Nothing fancy happens here: We only have to be careful to keep the
registration data consistent and allow to unregister the same and complete
set of classes that has been registered previously.

  1 for every selected CIMOM:
  2 if (MOFs/REG not in the same registration || unknown) {
  3     exit with error
  4     unregister in the CIMOM
  5 }
  6 delete the database records (MOFs/REG, registration)
  7 delete the backup files

=============================================================================
Re-registration:

Should be simple: just reconstruct the command line from the database. The
ordering of the registration is determined by the timestamp of their initial
registration (updates don't change the timestamp).

  1 for every selected CIMOM {
  2     get MOFs/REG/namespaces/version in the reverse timestamp order
  3     re-run the CIMOM registration (using backup MOF/REG files)
  4 }

I'm not quite sure how clear I made myself with the ideas and I assume
many problems get spotted in the real world testing.  However if you have
some ideas or corrections... I'm all ear.

Thanks and regards,
-- 
Tomáš Smetana
Platform Engineering, Red Hat


More information about the openlmi-devel mailing list