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