[RFC] New provider registration process

Russell Doty rdoty at redhat.com
Mon Aug 19 20:24:04 UTC 2013


On Mon, 2013-08-19 at 12:22 +0200, Tomáš Smetana wrote:
> 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.
We need to make sure that Pegasus is installed for LMI.
> 
> 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.
As an alternative, can the script search for which Providers are
installed on the system and assume that we should register all installed
Providers? This would tie registration to package installation, rather
than making it a separate operation.

Assuming we do a registration database,it would also support query of
the Providers and versions installed?

Should the registration database feed information to OpenSLP?
> 
> 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,




More information about the openlmi-devel mailing list