[RFC] New provider registration process

Jan Safranek jsafrane at redhat.com
Wed Oct 23 10:57:11 UTC 2013


Now we have brand new openlmi-mof-register in openlmi-providers in git.
Preliminary tests shows that it works as expected, at least on package
installation/removal.

Please test it as much as possible and report any issues.


Jan

On 08/19/2013 12:22 PM, 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.
> 
> 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,
> 



More information about the openlmi-devel mailing list