[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