Re: rtsadmin-v1.99 BETA packages

Re: rtsadmin-v1.99 BETA packages

[Andy Grover]

[CCing lists too.]

Hi Nicholas,

Thank you to you, Jerome and RTS for this work!

The rtsadmin-frozen rpm from 04-May-2011 installed ok but didn't seem to
work quite right, but I wouldn't worry about it. I'm working on rpm
packages with proper dependencies for Fedora rawhide, hopefully they'll
be ready within a few days and I can make binary+src rpms available.

Regards -- Andy

On 05/04/2011 05:03 PM, Nicholas A. Bellinger wrote:
> On Fri, 2011-04-29 at 17:01 -0700, Nicholas A. Bellinger wrote:
>> Greetings all,
>>
>> It's my great pleasure to be able to share the initial RTSAdmin v1.99
>> BETA 64-bit userspace packages here:
>>
> 
> Hello again folks,
> 
> Just a few updates on our BETA progress in the last week.  We have
> updated the rtsadmin-v2 frozen and lio-utils packages for Debian Squeeze
> and RHEL6 64-bit userspace here:
> 
> http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/
> 
> This version of lio-utils contains support for tcm_qla2xxx, ib_srpt,
> tcm_fc and loopback fabric modules with the following operations:
> 
> *) rtsadmin-v2 'saveconfig' now creates /etc/target/$FABRICNAME_start.sh
> for active tcm_qla2xxx, ib_srpt, tcm_fc and loopback configurations.
> *) 'service target start' now re-creates the fabric configfs layout
> using available /etc/target/$FABRICNAME_start.sh from currently saved
> fabrics.
> *) 'service target startbak $TIMESTAMP' now re-creates the fabric
> configfs layout via /etc/target/backup/$FABRICNAME_backup-$TIMESTAMP.sh
> from previously saved fabrics.
> *) 'service target stop' will unload the current running configuration
> for all active fabric modules and target core.
> 
> Unfortuately the frozen RPM package is currently having issues running
> with RHEL6-final, so getting up and running on RHEL6 from source takes a
> little bit of effort to manually install the python simpleparse library
> which is currently not packaged for RHEL6.  Instructions for this and
> other distros be added into the rtsadmin-v2 wiki shortly.
> 
> Also, we have setup the public rtsadmin-v2 community repository for
> configshell.git, rtslib.git and rtsadmin.git source repos for those
> interested in having a look at the code:
> 
> http://www.risingtidesystems.com/git/
> 
> Feedback is welcome, and please let us know if you have any issues
> getting setup with the v2 shell.
> 
> --nab
> 
> 
>>
>> So far this is going out to Linux/SCSI community members who are
>> currently using the target core v4.0 + fabric module logic with the
>> default set of 5 specs included in the initial BETA release.
>>
>> We have been testing the .deb builds on Debian Squeeze 64-bit and .rpm
>> builds on RHEL6 64-bit thus far.  On this kernel side, this includes
>> support for the following target core + fabric module configurations:
>>
>> Target v4.x with >= .38 based lio-core-2.6.git code:
>>
>> 	iscsi-target
>>         tcm_loop
>>         tcm_fc(openfcoe)
>>         tcm_qla2xxx
>>         ib_srpt
>>
>> Target v3.5.x out-of-tree lio-core-backports.git code
>>
>>         iscsi-target
>>         tcm_loop
>>
>> The first round of rtsadmin-v2 specific fabric module information has
>> been added into the wiki below.  This includes example usage for
>> configuring Qlogic with demo mode TPG, and IB SRPT using explict SRP
>> Initiator NodeACLs + MappedLUNs along with similar instructions for
>> Open-FCoE.org target, and TCM_Loop LLD driver.
>>
>> http://linux-iscsi.org/wiki/QLogic/rtsadmin-v2
>> http://linux-iscsi.org/wiki/SCSI_RDMA_Protocol/rtsadmin-v2
>> http://linux-iscsi.org/wiki/FCoE/rtsadmin-v2
>> http://linux-iscsi.org/wiki/Tcm_loop/rtsadmin-v2
>>
>> We will be adding more usage examples and tips+tricks into the wiki in
>> the upcoming days, but please feel free to try out the initial packages,
>> and let us know if you have any problems getting setup.  Note there are
>> a handful of items missing from these builds, most notiably being able
>> to save non iscsi-target + tcm_loop fabrics layouts across
>> init.d/target restart.  This will be addressed along with our other
>> remaining items for a follow-up release next week.
>>
>> >From there we will be ironing out remaining bugs and finishing up
>> remaining the TODO list. We intend to release the community version via
>> git source tree and announce the new develpoer and user mailing lists in
>> the upcoming weeks as we more toward a stable v2 release.
>>
>> Also, the 'collapsed tpg' feature has been included in this build based
>> on Tomo's feedback which hides the 'tpgt' by default with non iSCSI
>> fabrics.  This ends up looking like the following with 'ls . 2' (eg: to
>> limit the object output to tree_max_depth=2) with five fabric modules
>> running in mixed-mode on .38.3 code with bare-metal 5600 series
>> hardware:
>>
>> /> ls . 2
>> o-/ ...................................................................... [...]
>>   o-backstores .................................................. [2 Backstores]
>>   | o-iblock0 ............................................... [1 Storage Object]
>>   | o-iblock1 ............................................... [1 Storage Object]
>>   o-ib_srpt ........................................................ [2 Targets]
>>   | o-0x00000000000000000002c903000e8acd ............................. [enabled]
>>   | o-0x00000000000000000002c903000e8ace ............................. [enabled]
>>   o-iscsi ........................................................... [1 Target]
>>   | o-iqn.2003-01.org.linux-iscsi.tifa.x8664:sn.2e732952bb1a ........... [1 TPG]
>>   o-loopback ....................................................... [2 Targets]
>>   | o-naa.6001405c3214b06a .............................. [naa.6001405305bd4088]
>>   | o-naa.6001405d500c6966 .............................. [naa.600140589253c5ee]
>>   o-qla2xxx ........................................................ [2 Targets]
>>   | o-21:00:00:24:ff:31:4c:48 ........................................ [enabled]
>>   | o-21:00:00:24:ff:31:4c:49 ........................................ [enabled]
>>   o-tcm_fc .......................................................... [1 Target]
>>     o-20:00:00:15:17:af:5b:30 ........................................ [enabled]
>> /> 
>>
>> We are very interested to get your feedback on the v2 shell.  Please
>> have a look and let myself and Jerome know if you run into trouble
>> getting installed and running.
>>
>> --nab
>>
> 

Re: rtsadmin-v1.99 BETA packages

[mwf]

Andy,

Thank you for working with us to productize rtsadmin and putting together a great package!

Best,
Marc

Sent via BlackBerry from T-Mobile

-----Original Message-----
From: Andy Grover <agrover@redhat.com>
Date: Wed, 11 May 2011 09:59:33 
To: <nab@risingtidesystems.com>
Cc: Mike Christie<michaelc@cs.wisc.edu>; Christoph Hellwig<hch@lst.de>; Hannes Reinecke<hare@suse.de>; James Bottomley<James.Bottomley@suse.de>; Boaz Harrosh<openosd@gmail.com>; Patil, Kiran<kiran.patil@intel.com>; Love, Robert W<robert.w.love@intel.com>; Madhu Iyengar<madhu.iyengar@qlogic.com>; Andrew Vasquez<andrew.vasquez@qlogic.com>; Jerome Martin<jxm@risingtidesystems.com>; Marc Fleischmann<mwf@risingtidesystems.com>; FUJITA Tomonori<fujita.tomonori@lab.ntt.co.jp>; J.H.<warthog9@kernel.org>; H. Peter Anvin<hpa@zytor.com>; Matthew Wilcox<matthew@wil.cx>; Stefan Hajnoczi<stefanha@gmail.com>; linux-iscsi-target-dev<linux-iscsi-target-dev@googlegroups.com>; <linux-scsi@vger.kernel.org>
Subject: Re: rtsadmin-v1.99 BETA packages

[CCing lists too.]

Hi Nicholas,

Thank you to you, Jerome and RTS for this work!

The rtsadmin-frozen rpm from 04-May-2011 installed ok but didn't seem to
work quite right, but I wouldn't worry about it. I'm working on rpm
packages with proper dependencies for Fedora rawhide, hopefully they'll
be ready within a few days and I can make binary+src rpms available.

Regards -- Andy

On 05/04/2011 05:03 PM, Nicholas A. Bellinger wrote:
> On Fri, 2011-04-29 at 17:01 -0700, Nicholas A. Bellinger wrote:
>> Greetings all,
>>
>> It's my great pleasure to be able to share the initial RTSAdmin v1.99
>> BETA 64-bit userspace packages here:
>>
> 
> Hello again folks,
> 
> Just a few updates on our BETA progress in the last week.  We have
> updated the rtsadmin-v2 frozen and lio-utils packages for Debian Squeeze
> and RHEL6 64-bit userspace here:
> 
> http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/
> 
> This version of lio-utils contains support for tcm_qla2xxx, ib_srpt,
> tcm_fc and loopback fabric modules with the following operations:
> 
> *) rtsadmin-v2 'saveconfig' now creates /etc/target/$FABRICNAME_start.sh
> for active tcm_qla2xxx, ib_srpt, tcm_fc and loopback configurations.
> *) 'service target start' now re-creates the fabric configfs layout
> using available /etc/target/$FABRICNAME_start.sh from currently saved
> fabrics.
> *) 'service target startbak $TIMESTAMP' now re-creates the fabric
> configfs layout via /etc/target/backup/$FABRICNAME_backup-$TIMESTAMP.sh
> from previously saved fabrics.
> *) 'service target stop' will unload the current running configuration
> for all active fabric modules and target core.
> 
> Unfortuately the frozen RPM package is currently having issues running
> with RHEL6-final, so getting up and running on RHEL6 from source takes a
> little bit of effort to manually install the python simpleparse library
> which is currently not packaged for RHEL6.  Instructions for this and
> other distros be added into the rtsadmin-v2 wiki shortly.
> 
> Also, we have setup the public rtsadmin-v2 community repository for
> configshell.git, rtslib.git and rtsadmin.git source repos for those
> interested in having a look at the code:
> 
> http://www.risingtidesystems.com/git/
> 
> Feedback is welcome, and please let us know if you have any issues
> getting setup with the v2 shell.
> 
> --nab
> 
> 
>>
>> So far this is going out to Linux/SCSI community members who are
>> currently using the target core v4.0 + fabric module logic with the
>> default set of 5 specs included in the initial BETA release.
>>
>> We have been testing the .deb builds on Debian Squeeze 64-bit and .rpm
>> builds on RHEL6 64-bit thus far.  On this kernel side, this includes
>> support for the following target core + fabric module configurations:
>>
>> Target v4.x with >= .38 based lio-core-2.6.git code:
>>
>> 	iscsi-target
>>         tcm_loop
>>         tcm_fc(openfcoe)
>>         tcm_qla2xxx
>>         ib_srpt
>>
>> Target v3.5.x out-of-tree lio-core-backports.git code
>>
>>         iscsi-target
>>         tcm_loop
>>
>> The first round of rtsadmin-v2 specific fabric module information has
>> been added into the wiki below.  This includes example usage for
>> configuring Qlogic with demo mode TPG, and IB SRPT using explict SRP
>> Initiator NodeACLs + MappedLUNs along with similar instructions for
>> Open-FCoE.org target, and TCM_Loop LLD driver.
>>
>> http://linux-iscsi.org/wiki/QLogic/rtsadmin-v2
>> http://linux-iscsi.org/wiki/SCSI_RDMA_Protocol/rtsadmin-v2
>> http://linux-iscsi.org/wiki/FCoE/rtsadmin-v2
>> http://linux-iscsi.org/wiki/Tcm_loop/rtsadmin-v2
>>
>> We will be adding more usage examples and tips+tricks into the wiki in
>> the upcoming days, but please feel free to try out the initial packages,
>> and let us know if you have any problems getting setup.  Note there are
>> a handful of items missing from these builds, most notiably being able
>> to save non iscsi-target + tcm_loop fabrics layouts across
>> init.d/target restart.  This will be addressed along with our other
>> remaining items for a follow-up release next week.
>>
>> >From there we will be ironing out remaining bugs and finishing up
>> remaining the TODO list. We intend to release the community version via
>> git source tree and announce the new develpoer and user mailing lists in
>> the upcoming weeks as we more toward a stable v2 release.
>>
>> Also, the 'collapsed tpg' feature has been included in this build based
>> on Tomo's feedback which hides the 'tpgt' by default with non iSCSI
>> fabrics.  This ends up looking like the following with 'ls . 2' (eg: to
>> limit the object output to tree_max_depth=2) with five fabric modules
>> running in mixed-mode on .38.3 code with bare-metal 5600 series
>> hardware:
>>
>> /> ls . 2
>> o-/ ...................................................................... [...]
>>   o-backstores .................................................. [2 Backstores]
>>   | o-iblock0 ............................................... [1 Storage Object]
>>   | o-iblock1 ............................................... [1 Storage Object]
>>   o-ib_srpt ........................................................ [2 Targets]
>>   | o-0x00000000000000000002c903000e8acd ............................. [enabled]
>>   | o-0x00000000000000000002c903000e8ace ............................. [enabled]
>>   o-iscsi ........................................................... [1 Target]
>>   | o-iqn.2003-01.org.linux-iscsi.tifa.x8664:sn.2e732952bb1a ........... [1 TPG]
>>   o-loopback ....................................................... [2 Targets]
>>   | o-naa.6001405c3214b06a .............................. [naa.6001405305bd4088]
>>   | o-naa.6001405d500c6966 .............................. [naa.600140589253c5ee]
>>   o-qla2xxx ........................................................ [2 Targets]
>>   | o-21:00:00:24:ff:31:4c:48 ........................................ [enabled]
>>   | o-21:00:00:24:ff:31:4c:49 ........................................ [enabled]
>>   o-tcm_fc .......................................................... [1 Target]
>>     o-20:00:00:15:17:af:5b:30 ........................................ [enabled]
>> /> 
>>
>> We are very interested to get your feedback on the v2 shell.  Please
>> have a look and let myself and Jerome know if you run into trouble
>> getting installed and running.
>>
>> --nab
>>
> 

Re: rtsadmin-v1.99 BETA packages

[Nicholas A. Bellinger]

On Wed, 2011-05-11 at 09:59 -0700, Andy Grover wrote:
> [CCing lists too.]
> 
> Hi Nicholas,
> 
> Thank you to you, Jerome and RTS for this work!
> 
> The rtsadmin-frozen rpm from 04-May-2011 installed ok but didn't seem to
> work quite right, but I wouldn't worry about it. I'm working on rpm
> packages with proper dependencies for Fedora rawhide, hopefully they'll
> be ready within a few days and I can make binary+src rpms available.
> 

Hey Andy,

Thanks alot for this status update wrt to rtsadmin-v2 userspace.  I am
really looking forward to seeing rtsadmin-v2 community edition available
very soon in Fedora rawhide.  We (RTS) are also very excited to expose
the v2 shell to a larger audience using mainline >= .38 target v4
infrastructure.

We believe that having an interactive target shell and python library
available to developers and users is criticaly important to the success
of the mainline target ecosystem as a whole.  We are very proud to be
able to work with the upstream community to achieve this important
milestone with the v2 shell.

Thank you Andy!!

--nab


> Regards -- Andy
> 
> On 05/04/2011 05:03 PM, Nicholas A. Bellinger wrote:
> > On Fri, 2011-04-29 at 17:01 -0700, Nicholas A. Bellinger wrote:
> >> Greetings all,
> >>
> >> It's my great pleasure to be able to share the initial RTSAdmin v1.99
> >> BETA 64-bit userspace packages here:
> >>
> > 
> > Hello again folks,
> > 
> > Just a few updates on our BETA progress in the last week.  We have
> > updated the rtsadmin-v2 frozen and lio-utils packages for Debian Squeeze
> > and RHEL6 64-bit userspace here:
> > 
> > http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/
> > 
> > This version of lio-utils contains support for tcm_qla2xxx, ib_srpt,
> > tcm_fc and loopback fabric modules with the following operations:
> > 
> > *) rtsadmin-v2 'saveconfig' now creates /etc/target/$FABRICNAME_start.sh
> > for active tcm_qla2xxx, ib_srpt, tcm_fc and loopback configurations.
> > *) 'service target start' now re-creates the fabric configfs layout
> > using available /etc/target/$FABRICNAME_start.sh from currently saved
> > fabrics.
> > *) 'service target startbak $TIMESTAMP' now re-creates the fabric
> > configfs layout via /etc/target/backup/$FABRICNAME_backup-$TIMESTAMP.sh
> > from previously saved fabrics.
> > *) 'service target stop' will unload the current running configuration
> > for all active fabric modules and target core.
> > 
> > Unfortuately the frozen RPM package is currently having issues running
> > with RHEL6-final, so getting up and running on RHEL6 from source takes a
> > little bit of effort to manually install the python simpleparse library
> > which is currently not packaged for RHEL6.  Instructions for this and
> > other distros be added into the rtsadmin-v2 wiki shortly.
> > 
> > Also, we have setup the public rtsadmin-v2 community repository for
> > configshell.git, rtslib.git and rtsadmin.git source repos for those
> > interested in having a look at the code:
> > 
> > http://www.risingtidesystems.com/git/
> > 
> > Feedback is welcome, and please let us know if you have any issues
> > getting setup with the v2 shell.
> > 
> > --nab
> > 
> > 
> >>
> >> So far this is going out to Linux/SCSI community members who are
> >> currently using the target core v4.0 + fabric module logic with the
> >> default set of 5 specs included in the initial BETA release.
> >>
> >> We have been testing the .deb builds on Debian Squeeze 64-bit and .rpm
> >> builds on RHEL6 64-bit thus far.  On this kernel side, this includes
> >> support for the following target core + fabric module configurations:
> >>
> >> Target v4.x with >= .38 based lio-core-2.6.git code:
> >>
> >> 	iscsi-target
> >>         tcm_loop
> >>         tcm_fc(openfcoe)
> >>         tcm_qla2xxx
> >>         ib_srpt
> >>
> >> Target v3.5.x out-of-tree lio-core-backports.git code
> >>
> >>         iscsi-target
> >>         tcm_loop
> >>
> >> The first round of rtsadmin-v2 specific fabric module information has
> >> been added into the wiki below.  This includes example usage for
> >> configuring Qlogic with demo mode TPG, and IB SRPT using explict SRP
> >> Initiator NodeACLs + MappedLUNs along with similar instructions for
> >> Open-FCoE.org target, and TCM_Loop LLD driver.
> >>
> >> http://linux-iscsi.org/wiki/QLogic/rtsadmin-v2
> >> http://linux-iscsi.org/wiki/SCSI_RDMA_Protocol/rtsadmin-v2
> >> http://linux-iscsi.org/wiki/FCoE/rtsadmin-v2
> >> http://linux-iscsi.org/wiki/Tcm_loop/rtsadmin-v2
> >>
> >> We will be adding more usage examples and tips+tricks into the wiki in
> >> the upcoming days, but please feel free to try out the initial packages,
> >> and let us know if you have any problems getting setup.  Note there are
> >> a handful of items missing from these builds, most notiably being able
> >> to save non iscsi-target + tcm_loop fabrics layouts across
> >> init.d/target restart.  This will be addressed along with our other
> >> remaining items for a follow-up release next week.
> >>
> >> >From there we will be ironing out remaining bugs and finishing up
> >> remaining the TODO list. We intend to release the community version via
> >> git source tree and announce the new develpoer and user mailing lists in
> >> the upcoming weeks as we more toward a stable v2 release.
> >>
> >> Also, the 'collapsed tpg' feature has been included in this build based
> >> on Tomo's feedback which hides the 'tpgt' by default with non iSCSI
> >> fabrics.  This ends up looking like the following with 'ls . 2' (eg: to
> >> limit the object output to tree_max_depth=2) with five fabric modules
> >> running in mixed-mode on .38.3 code with bare-metal 5600 series
> >> hardware:
> >>
> >> /> ls . 2
> >> o-/ ...................................................................... [...]
> >>   o-backstores .................................................. [2 Backstores]
> >>   | o-iblock0 ............................................... [1 Storage Object]
> >>   | o-iblock1 ............................................... [1 Storage Object]
> >>   o-ib_srpt ........................................................ [2 Targets]
> >>   | o-0x00000000000000000002c903000e8acd ............................. [enabled]
> >>   | o-0x00000000000000000002c903000e8ace ............................. [enabled]
> >>   o-iscsi ........................................................... [1 Target]
> >>   | o-iqn.2003-01.org.linux-iscsi.tifa.x8664:sn.2e732952bb1a ........... [1 TPG]
> >>   o-loopback ....................................................... [2 Targets]
> >>   | o-naa.6001405c3214b06a .............................. [naa.6001405305bd4088]
> >>   | o-naa.6001405d500c6966 .............................. [naa.600140589253c5ee]
> >>   o-qla2xxx ........................................................ [2 Targets]
> >>   | o-21:00:00:24:ff:31:4c:48 ........................................ [enabled]
> >>   | o-21:00:00:24:ff:31:4c:49 ........................................ [enabled]
> >>   o-tcm_fc .......................................................... [1 Target]
> >>     o-20:00:00:15:17:af:5b:30 ........................................ [enabled]
> >> /> 
> >>
> >> We are very interested to get your feedback on the v2 shell.  Please
> >> have a look and let myself and Jerome know if you run into trouble
> >> getting installed and running.
> >>
> >> --nab
> >>
> > 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: rtsadmin-v1.99 BETA packages

[Andy Grover]

On 05/11/2011 05:30 PM, Nicholas A. Bellinger wrote:
> Thanks alot for this status update wrt to rtsadmin-v2 userspace.  I am
> really looking forward to seeing rtsadmin-v2 community edition available
> very soon in Fedora rawhide.  We (RTS) are also very excited to expose
> the v2 shell to a larger audience using mainline >= .38 target v4
> infrastructure.

Hi nab,

I've packaged rtsadmin + deps for f14 and f15, instead of rawhide.
Fedora 14/15 users can add this repo:

http://repos.fedorapeople.org/repos/grover/rtsadmin/fedora-rtsadmin.repo

These are currently lacking docs but are functional.

Do I need to package lio-utils, or will it (imho preferably) be merged
into rtsadmin before 2.0?

Also, RPM really likes to start with a tarball from upstream -- I made
these myself from git for this snapshot, but real, upstream tarballs are
of course preferable, and leads me to ask: when should we expect the
official 2.0 release?

> We believe that having an interactive target shell and python
> library available to developers and users is criticaly important to
> the success of the mainline target ecosystem as a whole. We are very
> proud to be able to work with the upstream community to achieve this
> important milestone with the v2 shell.

Of course, for rtsadmin packages *you* are the upstream. :)

Congrats -- Regards -- Andy

Re: rtsadmin-v1.99 BETA packages

[Nicholas A. Bellinger]

On Wed, 2011-05-11 at 18:26 -0700, Andy Grover wrote:
> On 05/11/2011 05:30 PM, Nicholas A. Bellinger wrote:
> > Thanks alot for this status update wrt to rtsadmin-v2 userspace.  I am
> > really looking forward to seeing rtsadmin-v2 community edition available
> > very soon in Fedora rawhide.  We (RTS) are also very excited to expose
> > the v2 shell to a larger audience using mainline >= .38 target v4
> > infrastructure.
> 
> Hi nab,
> 
> I've packaged rtsadmin + deps for f14 and f15, instead of rawhide.
> Fedora 14/15 users can add this repo:
> 
> http://repos.fedorapeople.org/repos/grover/rtsadmin/fedora-rtsadmin.repo
> 
> These are currently lacking docs but are functional.
> 
> Do I need to package lio-utils, or will it (imho preferably) be merged
> into rtsadmin before 2.0?
> 

Now that we do have a functional set for save/unload/restore ops with
lio-utils, this bit is considered medium priority in the short term as
the there are more important bits to enable for shell usability..

> Also, RPM really likes to start with a tarball from upstream -- I made
> these myself from git for this snapshot, but real, upstream tarballs are
> of course preferable, and leads me to ask: when should we expect the
> official 2.0 release?
> 

I expect by the time that .40 ships this fall we will have a stable v2.0
release with fully integrated save/restore logic from rtslib without any
legacy lio-utils dependencies.

> > We believe that having an interactive target shell and python
> > library available to developers and users is criticaly important to
> > the success of the mainline target ecosystem as a whole. We are very
> > proud to be able to work with the upstream community to achieve this
> > important milestone with the v2 shell.
> 
> Of course, for rtsadmin packages *you* are the upstream. :)
> 

:)

--nab

Re: rtsadmin-v1.99 BETA packages

[Nicholas A. Bellinger]

On Wed, 2011-05-11 at 17:30 -0700, Nicholas A. Bellinger wrote:
> On Wed, 2011-05-11 at 09:59 -0700, Andy Grover wrote:
> > [CCing lists too.]
> > 
> > Hi Nicholas,
> > 
> > Thank you to you, Jerome and RTS for this work!
> > 
> > The rtsadmin-frozen rpm from 04-May-2011 installed ok but didn't seem to
> > work quite right, but I wouldn't worry about it. I'm working on rpm
> > packages with proper dependencies for Fedora rawhide, hopefully they'll
> > be ready within a few days and I can make binary+src rpms available.
> > 
> 
> Hey Andy,
> 
> Thanks alot for this status update wrt to rtsadmin-v2 userspace.  I am
> really looking forward to seeing rtsadmin-v2 community edition available
> very soon in Fedora rawhide.  We (RTS) are also very excited to expose
> the v2 shell to a larger audience using mainline >= .38 target v4
> infrastructure.
> 
> We believe that having an interactive target shell and python library
> available to developers and users is criticaly important to the success
> of the mainline target ecosystem as a whole.  We are very proud to be
> able to work with the upstream community to achieve this important
> milestone with the v2 shell.
> 
> Thank you Andy!!
> 
> --nab
> 

Hello everyone,

Just a quick update on the userspace side..

This afternoon's updated RHEL6 and Debian Squeeze BETA builds are
available here:

http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/rtsadmin-frozen-11.99-20110513091048.3434628.x86_64.rpm
http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/rtsadmin-frozen_11.99-20110513161709.3434628_amd64.deb

These contain an important bugfix for v2 device creation where 
/sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial
was not being automatically generated for newly created virtual devices.
There is also a seperate multi-fabric export HBA context 'delete
$DEVICE_NAME' that has been fixed as well and pushed into the community
repo.

Also, the lio-utils v4.0 packages for RHEL6 and Debian Squeeze have been
updated with a few minor improvements to tcm_fabric.py code.

http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/lio-utils-4.0-d2cf595d.x86_64.rpm
http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/lio-utils_4.0_amd64.deb

Please let us know if you have any questions.

Thanks!

--nab

Re: rtsadmin-v1.99 BETA packages

[Andy Grover]

On 05/13/2011 06:41 PM, Nicholas A. Bellinger wrote:
> This afternoon's updated RHEL6 and Debian Squeeze BETA builds are
> available here:
> 
> http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/rtsadmin-frozen-11.99-20110513091048.3434628.x86_64.rpm
> http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/rtsadmin-frozen_11.99-20110513161709.3434628_amd64.deb
> 
> These contain an important bugfix for v2 device creation where 
> /sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial
> was not being automatically generated for newly created virtual devices.
> There is also a seperate multi-fabric export HBA context 'delete
> $DEVICE_NAME' that has been fixed as well and pushed into the community
> repo.
> 
> Also, the lio-utils v4.0 packages for RHEL6 and Debian Squeeze have been
> updated with a few minor improvements to tcm_fabric.py code.
> 
> http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/lio-utils-4.0-d2cf595d.x86_64.rpm
> http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/lio-utils_4.0_amd64.deb
> 
> Please let us know if you have any questions.

Hi nab and Jerome,

Could you explain the versioning of the rtsadmin-frozen packages? I
think the 2011.. is a datetime stamp, but I don't grok the 11.99 and
3434628.

Would it be possible to release src rpms/debs, or even a tar.gz, for
these as well?

Have you looked into putting these into yum or apt repos, for easy
upgrading?

Finally, I notice modified versions of the rpm specfiles I authored are
now in your rtsadmin[1], rtslib, and configshell repos. There is no
indication of origin or attribution to me or my employer. I think this
is technically ok since the files are licensed under the Fedora CLA[2],
but it is an accepted FOSS practice to say where you got something, at
least in the checkin notes.

I'm not sweating it, just letting you know :-)

But, this becomes a more significant issue when talking about code
contributions, and a potential non-free version of, or code that builds
on, rtsadmin. Once you accept outside contributions under the AGPLv3,
you are required to release the source of derivative works[3]. Could you
be a little clearer about your plans for a non-free version, and what
the boundary will be between it and the released code, so that we can
make contributions that do not end up in non-free code?

Thanks -- Regards -- Andy

[1]
http://www.risingtidesystems.com/git/?p=rtsadmin.git;a=commit;h=d9c8421c3df0f9a6b922903ba90df43068d687fa
[2] http://fedoraproject.org/wiki/Licensing#License_of_Fedora_SPEC_Files
[3] IANAL - I am not a lawyer.

Re: rtsadmin-v1.99 BETA packages

[Nicholas A. Bellinger]

On Sat, 2011-05-14 at 16:36 -0700, Andy Grover wrote:
> On 05/13/2011 06:41 PM, Nicholas A. Bellinger wrote:
> > This afternoon's updated RHEL6 and Debian Squeeze BETA builds are
> > available here:
> > 
> > http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/rtsadmin-frozen-11.99-20110513091048.3434628.x86_64.rpm
> > http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/rtsadmin-frozen_11.99-20110513161709.3434628_amd64.deb
> > 
> > These contain an important bugfix for v2 device creation where 
> > /sys/kernel/config/target/core/$HBA/$DEV/wwn/vpd_unit_serial
> > was not being automatically generated for newly created virtual devices.
> > There is also a seperate multi-fabric export HBA context 'delete
> > $DEVICE_NAME' that has been fixed as well and pushed into the community
> > repo.
> > 
> > Also, the lio-utils v4.0 packages for RHEL6 and Debian Squeeze have been
> > updated with a few minor improvements to tcm_fabric.py code.
> > 
> > http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/lio-utils-4.0-d2cf595d.x86_64.rpm
> > http://www.risingtidesystems.com/rtsadmin-v1.99-BETA/lio-utils_4.0_amd64.deb
> > 
> > Please let us know if you have any questions.
> 
> Hi nab and Jerome,

Hello Andy,

> 
> Could you explain the versioning of the rtsadmin-frozen packages? I
> think the 2011.. is a datetime stamp, but I don't grok the 11.99 and
> 3434628.
> 

To clarify the 3434628 suffix. The ability to build frozen packages has
not been included into the community edition branch, so these actually
reference commit IDs outside of what's in the public git repos.

Of course these trees are currently in sync with community edition
bugfixes.  Also, wrt to the 11.99 tag, I believe Jerome bumped this to
avoid old versioning issue with rpm -iUf..

> Would it be possible to release src rpms/debs, or even a tar.gz, for
> these as well?
> 

With the necessary python devel packages and dependencies installed, our
public rtslib.git, configshell.git and rtsadmin.git community edition
trees can 'make rpm' and 'make deb' with current code.  We are happy to
add these BETA packages for download as well, but as you can imagine
providing frozen builds is currently a bit easier for us wrt to python
dependencies to allow a larger audience access to current BETA builds.

> Have you looked into putting these into yum or apt repos, for easy
> upgrading?
> 

We are currently considering public community edition packages repos,
but in the end we would really like distro folks to provide our package
in their upstream package repos following our community edition trees
with necessary python2.6 dependencies in place.

> Finally, I notice modified versions of the rpm specfiles I authored are
> now in your rtsadmin[1], rtslib, and configshell repos. There is no
> indication of origin or attribution to me or my employer. I think this
> is technically ok since the files are licensed under the Fedora CLA[2],
> but it is an accepted FOSS practice to say where you got something, at
> least in the checkin notes.
> 
> I'm not sweating it, just letting you know :-)
> 

Sure, adding a copyright in a modified spec file that Jerome used from
your side is obvious overkill..  :)

> But, this becomes a more significant issue when talking about code
> contributions, and a potential non-free version of, or code that builds
> on, rtsadmin. Once you accept outside contributions under the AGPLv3,
> you are required to release the source of derivative works[3]. Could you
> be a little clearer about your plans for a non-free version, and what
> the boundary will be between it and the released code, so that we can
> make contributions that do not end up in non-free code?
> 

So to clarify here.  We intend to keep everything related to single
target management for rtslib/configshell/rtsadmin available under AGPLv3
on http://www.risingtidesystems.com/git/  This currently includes:

*) high level single node management, libs, and docs for target core
*) high level single node management, libs, and docs for fabrics using 
   the mainline target_core_fabric_config.c framework.
*) configshell python library and docs
*) Ability to build rpm/deb source packages with necessary dependecies

Our commerical versions will include a number of integrated features to
complement single node target core/fabric management, along with
allowing rtsadmin-v2 to function in a larger multi-node cluster
environment.

To the question of contributing code to the AGPLv3 licensed community
edition of rtslib/configshell/rtsadmin, we are doing a dual licensing
model like MySQL.   Please feel free to contact Marc directly with
specific questions that you may have wrt to licensing for our python
code.

--nab

Re: rtsadmin-v1.99 BETA packages

[Andy Grover]

On 05/17/2011 12:30 AM, Nicholas A. Bellinger wrote:
> So to clarify here.  We intend to keep everything related to single
> target management for rtslib/configshell/rtsadmin available under AGPLv3
> on http://www.risingtidesystems.com/git/  This currently includes:
> 
> *) high level single node management, libs, and docs for target core
> *) high level single node management, libs, and docs for fabrics using 
>    the mainline target_core_fabric_config.c framework.
> *) configshell python library and docs
> *) Ability to build rpm/deb source packages with necessary dependecies
> 
> Our commerical versions will include a number of integrated features to
> complement single node target core/fabric management, along with
> allowing rtsadmin-v2 to function in a larger multi-node cluster
> environment.
> 
> To the question of contributing code to the AGPLv3 licensed community
> edition of rtslib/configshell/rtsadmin, we are doing a dual licensing
> model like MySQL.   Please feel free to contact Marc directly with
> specific questions that you may have wrt to licensing for our python
> code.

Thanks for the clarification.

Regards -- Andy

Re: rtsadmin-v1.99 BETA packages

[Andy Grover]

On 05/17/2011 05:56 AM, Jerome Martin wrote:
>   Andy, in your own packaging, I noticed you got rid of the timestamps.
> Please don't, it is here for a good reason: It guarantees a proper
> version comparison/ordering across development builds, for both dpkg and
> rpm. If the version string seems lengthy to you, remember that those are
> just for for development builds, tagged ones will be much easier to the eye.

Sure, I did add a .0 after the 1.99 in order to allow for further
development rpms before 2.0, but I can see how timestamps would be
easier from an automation perspective.

In any case, since my rpm building process is rather manual, I'll
probably refrain from many more versions before release. I just wanted
to get something out there for my own use, and to get it in the pipeline
for distro inclusion.

> Last, but not least regarding your initial question, as Nic said, the
> frozen packages are not part of the OSS tree. In order to differentiate
> the non-OSS tree builds from the OSS ones, we prepend a '1' to the OSS
> tree version strings, allowing us to provide an upgrade path from OSS to
> non OSS (same packages names, but higher version, allows seemless
> upgrade), and also distinguish the packages easily. But please don't
> bother about that specific item, it is not relevant to the OSS branch,
> just mentioning it FYI :-)

Ok, thanks. I think for my purposes, I can ignore the -frozen packages,
and even pretend your non-OSS version doesn't exist, and go from there.

Regards -- Andy

Re: rtsadmin-v1.99 BETA packages

[Sangale Harshada Vijay]

Hi,
Your links seems to be down.Will you please let me know from where I could get
the latest rpm of rstadmin-frozen package?

Regards,
Harshada Sangale.