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,
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,
On Mon, 19 Aug 2013 16:24:04 -0400 Russell Doty rdoty@redhat.com wrote:
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.
<...>
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.
We may want to register things not necessarily backed by a provider (a profile for example). And for the providers: I need to determine also the right order of the registrations and the schemas the providers implement.
And yes, I don't think using the registration script outside the rpm scriptlets should be something usual -- only on very rare occasions should the user want to manually alter the registrations: still we need to keep this option.
Assuming we do a registration database,it would also support query of the Providers and versions installed?
Yes, we can list the database information.
Should the registration database feed information to OpenSLP?
No. It's the duty of the running CIMOM to advertise its capabilities through SLP.
Regards,
On Wed, 2013-08-21 at 13:13 +0200, Tomáš Smetana wrote:
On Mon, 19 Aug 2013 16:24:04 -0400 Russell Doty rdoty@redhat.com wrote:
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.
<...>
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.
We may want to register things not necessarily backed by a provider (a profile for example). And for the providers: I need to determine also the right order of the registrations and the schemas the providers implement.
And yes, I don't think using the registration script outside the rpm scriptlets should be something usual -- only on very rare occasions should the user want to manually alter the registrations: still we need to keep this option.
OK, thanks for the explanation.
Assuming we do a registration database,it would also support query of the Providers and versions installed?
Yes, we can list the database information.
Should the registration database feed information to OpenSLP?
No. It's the duty of the running CIMOM to advertise its capabilities through SLP.
Regards,
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,
openlmi-devel@lists.stg.fedorahosted.org
-
Jan Safranek -
Russell Doty -
Tomáš Smetana