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