RFC: Provider registration management

John Dennis jdennis at redhat.com
Fri May 17 13:06:14 UTC 2013


On 05/17/2013 05:34 AM, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, 2013-05-17 at 10:45 +0200, Jan Safranek wrote:
>
>> so far we register providers in rpm %post scripts. This has shown to be
>> error prone, the registration repositories are quite fragile and tend to
>> break.
>
> Do we have specifics about how they break?  Eg. if it's bugs with
> ordering/execution in rpm %post, those could equally apply to a new
> metadata repository; if it's just that they aren't reliable, there's
> nothing to say that they will necessarily be more reliable when used
> fropm a new provider registration manager.
>
>> As a solution, I can imagine we could add new package, let's say
>> cim-provider-register.rpm, with /bin/provider-register and
>> /lib/provider-register (or /etc/providers.d?).
>
>> The /lib/provider-register/ would be authoritative repository of
>> registered providers.
>
> This clearly adds something significant --- ability to repair existing
> provider registrations if breakage does happen, and much better
> resiliance around installing things out of order.  So it definitely
> sounds useful to have.
>
> But I'd still like to be sure we're addressing the fundamental
> registration problems, so that even when using the new repository to
> drive registration, it works reliably.

Stephen, some of the issues Jan is trying to address are captured in 
this bug

"provider registration fails if only one CIMOM is installed, failure is 
silent"
https://bugzilla.redhat.com/show_bug.cgi?id=961415

I can't speak as to how fragile the registration process has been or 
what the root causes might be (the most recent issue was a simple script 
bug that was quickly fixed). But to me the real problem is you often 
don't have a clear handle on why an installed provider does not work, a 
lot of times it comes down to registration issues (sometimes 
self-inflicted). The problem is further compounded by the fact (at least 
with pegasus) that the provider classes will be visible in the CIMOM 
(because the mof files got installed) but the provider is not functioning.

Also if the mof is updated one has to completely unregister and 
re-register (more of an issue during development but this will happen as 
we update providers in new releases). If the mof is updated but you 
haven't successfully unregistered and re-registered it can be 
particularly vexing because it appears the provider is installed and 
functioning but subtle things (such as a new/modified property) are not 
available. I made this mistake multiple times during development but at 
least I had a clear enough understanding of the mechanisms involved to 
be able after a few minutes to say "Duh! I know exactly why this isn't 
working, the registration is outdated".

All the above are just suggestion to make the technology more robust for 
those less familiar with it so there is less head scratching, better 
diagnostics and tools to set things straight if and when something goes 
wrong, either due to a bug or operator error.

John



-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/


More information about the openlmi-devel mailing list