proposal for naming of mof files

Jan Safranek jsafrane at redhat.com
Tue Apr 9 07:51:22 UTC 2013


On 04/09/2013 09:45 AM, Jan Synacek wrote:
> 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...

Yes, I'm in contact with upstream, but any solution there would take
some time.

> 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?

We don't have much dependencies between MOF files, basically only
Qualifiers and Jobs are included by someone else. This set might grow in
future, but I don't expect any big number.

So as a workaround, I am for this proposal.

Jan



More information about the openlmi-devel mailing list