RFC: Provider registration management

Russell Doty rdoty at redhat.com
Fri May 17 13:59:18 UTC 2013


On Fri, 2013-05-17 at 09:06 -0400, John Dennis wrote:
> 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".
Should we be versioning the MOF and Provider to keep them in sync?
> 
> 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
> 
> 
> 




More information about the openlmi-devel mailing list