implementation of nfs head

Jan Safranek jsafrane at redhat.com
Wed Sep 25 13:09:17 UTC 2013


On 09/25/2013 11:37 AM, sunil kumar wrote:
> hi
> 
> We are in implementation of nas head. need to know whether we are
> following the correct procedure of developing.
> 
> In the 60_LMI_Networking.mof file at the end we created the following
> association as told in smis profile..
> 
> /*******************************
>  * NAS Network PORTS Profile *
>  *******************************/
> [ Association, Provider("cmpi:cmpiLMI_Networking"), Version("0.1.0"),
>   Description("An association between a portocolendpoint and
> networkport.") ]
> class LMI_ProtocolDeviceSAPImplementation: CIM_DeviceSAPImplementation
> {
>     [ Key, Override("Antecedent"),
>       Description("The instance of CIM_ProtocolEndpoint subclass "
>         "representing network device.") ]
>     CIM_NetworkPort REF Antecedent;
> 
>     [ Key, Override("Dependent"),
>       Description("The instance of LMI_NetworkPort that represent "
>         "same device as Antecedent.") ]
>     CIM_ProtocolEndpoint REF Dependent;

Please use the right classes in associations, in this case you probably
want to associate to LMI_<something>ProcotolEndpoint. It speeds up
association traversal quite a lot.

> };
> 
> [ Provider("cmpi:cmpiLMI_Networking"), Version("0.1.0"),
> Description("End point protocol") ]
> 
> 
> we again complied and registered the mof file..
> 
> we got the new CMI_DeviseSAPImplemntaiton in src and in local/yawn..

The class definition looks fine. Question is, if the NAS HEAD profile
will be part of OpenLMI-Networking, OpenLMI-Storage or a separate provider.

The code above is part of OpenLMI-Networking. In my opinion, we should
keep the Networking provider just managing network interfaces and not
storage exports.

NAS head fits more to Storage provider, as it exports local filesystems
and we already have filesystem management there. Then it needs to be
written in Python and we don't use 'Provider("cmpi:cmpiLMI_Networking")'
in Storage MOF files (the rest is fine).

Or, if you want, you may develop a new provider, let's say OpenLMI-NAS,
either in C or Python, and just implement the profile + associations to
Networking and Storage LMI_ objects where appropriate. Feel free to
'steal' any CMake or Python snippets from other providers (mind the
license though).

We do not have any fixed procedure how to develop things, just follow
our coding guidelines [1] and test guidelines [2] and send your code to
our ReviewBoard [3]. We'll help you with anything, just let us know if
you have any troubles.

[1]: https://fedorahosted.org/openlmi/wiki/CodingConventions
[2]: https://fedorahosted.org/openlmi/wiki/TestGuidelines
[3]: https://reviewboard-openlmi.rhcloud.com/

Also, please let us know if there is something missing or misleading in
our documentation, we'll fix it. E.g. I created a ticket to improve our
README files based on your feedback:
https://fedorahosted.org/openlmi/ticket/152

Jan


More information about the openlmi-devel mailing list