[iSNS-discussion] Re: some thoughts about possible roadmap

[Ming Z. <mi...@el...>]

On Fri, 2005-04-08 at 18:27 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2005-04-08 at 20:28 -0400, Ming Zhang wrote:
> > On Fri, 2005-04-08 at 16:13 -0700, Nicholas A. Bellinger wrote:
> > > On Fri, 2005-04-08 at 15:38 -0400, Ming Zhang wrote:
> > > > Suggest to divide the development into at least 3 stages.
> > > > 
> > > > 1) implement core function, have a workable solution. a release 1.0
> > > > 2) implement secondary functionalities. 
> > > > 3) some 
> > > > 
> > > > Some stage 1 tasks are
> > > > 
> > > > * Code cleanup:
> > > > 	Support Linux 32bit/64bit.
> > > > * Support TCP for transport
> > > > 
> > > 
> > > Also includes:
> > > 
> > > A) iSNS client taking command line arguements for various discovery
> > > domain operations
> > yes, we need this.
> > 
> > 
> > > B) iSNS client calling other userspace programs based upon what mode the
> > > iSNS client is running in (initiator/target/both) (initiator-ctl in
> > > iscsi-initiator-core.org's case) to perform actions based upon the
> > > response, or asynchronous messages from the iSNS server.
> > > 
> > is this a good way or we should call isns action from ini or target?
> > 
> 
> Depends on the action.  The example of initial initiator node
> registration with the iSNS server is an iSNS client action.  The iSNS
> server contacting target nodes that a new initiator node is available is
> an iSNS server action.  My point is that both ways are needed:
> 
> A) iSNS client action == from the iSNS client command line
> B) iSNS server action == from the iSNS daemon to an external program for
> initiator/target node [re]configuration
> 
ic. so u mean a 2-way communications. yes, the scn need this and we
definitely need to support it.

> 
> > 
> > > Also, I need to read up on the iSNS RFC again, I don't think we need to
> > > go above what the draft says (its UDP with application layer checksums
> > > right?)
> > > 
> > yes, i need to read it again as well. today i did a quick read and get
> > refreshed.
> > 
> > > > Some stage 2 tasks are
> > > > * SCN
> > > > * for iSNS service discovery, 2.5.1, 2.5.3
> > > > * snmp support by net-snmp
> > > > 
> > > 
> > > As mentioned above, I need to read up on all of this.
> > > 
> > > > Some stage 3 tasks are
> > > > * 2.7 iSNS server fail over and synchronization.
> > > > 
> > > > 
> > > > Some extra thoughts.
> > > > 
> > > > 
> > > > * Must provide a persistence-neutral way to store the iSNS database. It
> > > > can be a Berkley DB or a complete openlDAP solution. so a wrapper is
> > > > needed to isolate the main code from it.
> > > > 
> > > 
> > > Berkley DB is what we want in this case.  OpenLDAP would be used for
> > > storing the authentication information in a single locate.  The OpenLDAP
> > > clients would be running on each Initiator node.
> > > 
> > fine.
> > 
> 
> This was just based on my knowledge of LDAP.  I always understand that
> the primary use of LDAP is as a single repository for authentication
> information, and not for storing large amounts of generic data in a
> database style format..?
> 
hehe. i might know a little more than you. it is ok for ldap to hold
data like isns info, anyway it is K of records not M of records.

see page 8, 2.1.4 isns database.

ming