5:22 a.m.
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
3:24 p.m.
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,
6:13 a.m.
On Mon, 19 Aug 2013 16:24:04 -0400
Russell Doty <rdoty(a)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,
--
Tomáš Smetana
Platform Engineering, Red Hat
4:58 p.m.
On Wed, 2013-08-21 at 13:13 +0200, Tomáš Smetana wrote:
On Mon, 19 Aug 2013 16:24:04 -0400
Russell Doty <rdoty(a)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,
5:57 a.m.
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,
3842
days inactive
3907
days old
openlmi-devel@lists.fedorahosted.org
4 comments
3 participants
participants (3)
-
Jan Safranek -
Russell Doty -
Tomáš Smetana