RFC: Provider registration management

John Dennis jdennis at redhat.com
Fri May 17 12:44:35 UTC 2013


On 05/17/2013 04:45 AM, Jan Safranek wrote:
> Hi,
>
> 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.
>
> 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?).

Why does it need to be a new separate RPM and not part of 
openlmi-providers which currently contains the openlmi-mof-register 
suite of tools?

Also you'll want to be careful with namespacing. Names like "provider" 
are too generic, it should be tied to "cim" in some fashion. I'm not 
sure any of this belongs under /lib. If you're putting stuff in 
/usr/lib, /etc/, /var/lib etc. they should probably have their own 
directory to keep things separate.

Also I don't think the tools belong in either /bin or /usr/bin, these 
types of tools are administration tools and belong in /usr/sbin, or so I 
believe, see bug https://bugzilla.redhat.com/show_bug.cgi?id=961434

>
> The /lib/provider-register/ would be authoritative repository of
> registered providers.
>
> * /bin/provider-register would have capability re-register all providers
> from /lib/provider-register to all installed CIMOMs. Useful when an user
> breaks something.
>
> * All rpm packages with CIM providers (incl. SBLIM ones) would add some
> registration metadata to /lib/provider-register/.
>
> * All rpm packages with CIM providers (incl. SBLIM ones) would register
> the provider in its %post script and deregister the providers in %preun
> script.
>
> * CIMOM rpm package would add all providers from /lib/provider-register
> to its repository in %post script. This fixes situation when a CIMOM is
> installed _after_ a provider.

I like the idea (with the caveats above) of a central registry and being 
able to operate on installed providers. In addition to being able to 
repair registrations one should also be able to enumerate them.

> * It could be also possible to update CIMOM registrations in CIMOM's
> unit file. I.e. when a CIMOM starts, it would get refreshed with
> registrations from /lib/provider-register.

I don't think this is a good idea for a variety of reasons. Registration 
is a configuration operation and configuration and/or modifying the 
behaviour of a daemon should not be silently performed when the service 
is started. Modifying service behavior should be explicit.

>
> While this approach fixes most problems with provider registration, this
> registration management is different to upstream one. E.g. when an admin
> reads Pegasus admin guide and removes a provider according to it, we
> will add the provider back on next Pegasus restart. We would need to
> carefully describe our new approach, but where?
>
> Jan
> _______________________________________________
> openlmi-devel mailing list
> openlmi-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/openlmi-devel
>


-- 
John Dennis <jdennis at redhat.com>

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


More information about the openlmi-devel mailing list