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