proposal for naming of mof files

Jan Synacek jsynacek at redhat.com
Tue Apr 9 07:45:16 UTC 2013


On 04/09/2013 08:52 AM, Michal Minář wrote:
> Hello,
> 
> I'd like to propose a simple change to naming our mof files to make their
> installation more reliable. There is a small shortcoming in sfcb mof
> registration scripts. They are parsed only once sorted by their name. If there
> occurs one class/instance or any other object in this compilation process, that
> does not have some of its dependencies (like parent class or property qualifier)
> already compiled, the compilation stops.
> 
> Consider the following example:
> 
>  * LMI_Qualifiers.mof - defines Implemented qualifier used by mof files
>    of at least storage and software profiles.
> 
>  * LMI_Jobs.mof - defines base classes for asynchronous job management
>    supposed to be inherited by other classes of particular profile. It
>    uses Implemented qualifier. Therefore it depends on LMI_Qualifiers.mof.
>  * LMI_Software.mof- the one and only mof file of software profile.
>    Also uses Implemented qualifier and moreover it inherits some
>    classes from LMI_Jobs.mof.
>      o Therefore it depends on both LMI_Qualifiers.mof and LMI_Jobs.mof.
> 
> If we sort these mof files by name we get: LMI_Jobs.mof, LMI_Software.mof,
> LMI_Qualifiers.mof.
> Upon invocation of
>     $ sfcbrepos -f
> We get a lot of errors like this one:
>     error in /var/lib/sfcb/stage/mofs/root/cimv2/LMI_Software.mof line 106 near
> true: Implemented is not a known qualifier
> 
> Because Implemented would come as last - a lot later, than it is needed. If
> LMI_Software.mof had a name LMI_Applications.mof instead, it would miss
> definitions from two files and so on.
> 
> *Note* that this is only problem of sfcb cimom, pegasus is smarter.
> 
> I searched for a way to avoid this and found out, that even sfcb's own mof files
> located in
> /var/lib/sfcb/stage/mofs/root/interop
> are named with pattern *NN_name.mof*, where *NN* are digits ensuring corrent
> order of files upon
> compilation.
> 
> I guess, that we will share more common definitions across our providers in the
> near future. So I think, that it would be desirable to establish a convention
> for naming mof files, that would ensure their correct installation in "not so
> smart" cimoms. And we should do it soon.
> 
> My proposal is: let's do it like sfcb:
> *NN_LMI_ProfileName.mof
> *
> 
> And let's also specify some advisable numbers. For example:
> 
>  * 05 - 10 - qualifiers and other simple mofs without any dependencies
>    on LMI or anything outside of cim-schema (05_LMI_Qualifiers.mof).
>    These will be shipped with openlmi-providers.
>  * 20 - 40 - mofs with base classes for our providers
>    (30_LMI_Jobs.mof). Also shipped with openlmi-providers.
>  * 50 - 80 - mofs of our profiles shipped in their own package
>    (60_LMI_Software.mof).
> 
> This is a request for comments. Please share your own ideas on how to solve this
> issue.

I guess that fixing sfcb would be the way to solve this:) If, of course, this
applies only to sfcb...

The idea looks ok to me. However, I can see a few possible issues with your
proposal. How frequently can the mofs be dependent on each other? If a lot then
manual dependency solving might get out of hand pretty quickly. How many mofs do
we expect to be in the project over time? Won't a triple-digit prefix be better?

-- 
Jan Synacek
Software Engineer, Red Hat


More information about the openlmi-devel mailing list