LMI_NASProtocolEndpoint code

ganesh kumar ganeshkumar14 at gmail.com
Thu Oct 10 09:25:36 UTC 2013


On Thu, Oct 10, 2013 at 2:43 PM, Radek Novacek <rnovacek at redhat.com> wrote:

> On Thu 10 of Oct 2013 14:08:58 ganesh kumar wrote:
> > Until now we were trying to extend the existing providers.
>
> For ease of development you can continue to extend existing providers.
> Separation to a new provider should be quite straight forward.
>
> > If developing a new Nas provider is what it takes to make a contribution
> to
> > OpenLMI, we will start working on it immediately.
>
> Yes, we would like to have the NAS provider as separate provider (but still
> part of the openlmi-providers). What features do you plan to add?
>

We are working on NFS share.

>
> > we hope your guidance will continue in the same way....
>
> We'll try to do our best.
>
>
> Radek Novacek
>
> > On Wed, Oct 9, 2013 at 4:56 PM, Radek Novacek <rnovacek at redhat.com>
> wrote:
> > > On Wed 09 of Oct 2013 16:31:33 ganesh kumar wrote:
> > > > Hi,
> > > >
> > > >  We are implemented "NAS Network Ports" profile, Started with
> > > >
> > > > ProtocolEndpoint class, we implemented "LMI_NASProtocolEndpoint"
> class,
> > > > please review our code.
> > > >
> > > > And also i have some doubt, How to add a condition when ever NFS
> process
> > > > runs it has to create an instance in NASProtocolEndpoint class, what
> > >
> > > logic
> > >
> > > > should i use?
> > >
> > > Hi,
> > >
> > > I understand the SNIA NAS Network Port Profile quite differently. I
> > > believe
> > > that there should be one instance of LMI_NASProtocolEndpoint for each
> NFS
> > > or
> > > CIFS share in the system, not for each network port. This
> > > LMI_NASProtocolEndpoint instance should be associated with existing
> > > LMI_NetworkPorts through DeviceSAPImplementation.
> > >
> > > May I ask if you're intending to submit your work to OpenLMI project?
> If
> > > so,
> > > please make the NAS provider an individual provider in the
> > > openlmi-providers
> > > repository (not part of networking provider). You can still depend on
> > > classes
> > > from networking provider, but we believe that this provider shouldn't
> be
> > > part
> > > of the networking provider itself.
> > >
> > > We would be glad to include your contribution into the OpenLMI Project
> > > once it
> > > will be conceptually and formally correct.
> > >
> > > Radek Novacek
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/openlmi-devel/attachments/20131010/e7198ec6/attachment.html>


More information about the openlmi-devel mailing list