linuxisns-discussion

[iSNS-discussion] some thoughts about possible roadmap

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

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

Some stage 2 tasks are
* SCN
* for iSNS service discovery, 2.5.1, 2.5.3
* snmp support by net-snmp

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.

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

[Nicholas A. B. <na...@ke...>]

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
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.

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?)

> 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.

> 

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

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

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?


> 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.

> > 
> 
> 

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

[Nicholas A. B. <na...@ke...>]

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


> 
> > 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..?

-- 
Nicholas A. Bellinger <na...@ke...>

[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