Re: how to script with targetcli

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2013-10-11 at 15:41 -0700, Nicholas A. Bellinger wrote:
> On Fri, 2013-10-11 at 10:24 -0700, Andy Grover wrote:
> > On 10/11/2013 08:09 AM, Seth Call wrote:
> > > I'm porting an application which runs on OpenIndiana.  In OpenIndiana,
> > > we just invoke itadm and stmfadm to create and destroy ISCSI targets.
> > >
> > > The command targetcli, however, seems a bit unfriendly to scripting in
> > > this fashion, seeing how it's interactive and all.
> > >
> > > I found this patch, and applied it, and it's allowed me to invoke
> > > targetcli as a one-liner, like:
> > >
> > > targetcli /iscsi create iqn.a.b.c:x
> > >
> > > Unfortunately, if the command fails, the exit code is still always 0.
> > > patch: http://www.spinics.net/lists/target-devel/msg01554.html
> > >
> > > But forget my approach for a second--I feel I might be missing how
> > > this is usually done. Does anyone script using targetcli, or do they
> > > use some other command instead?
> > 
> > This is a longtime issue with targetcli. Errors are not propagated all 
> > the way up to a single place that would make exiting with an error code 
> > possible. Alternatives include:
> > 
> > 1) Poking configfs yourself, directly or with lio-utils
> 
> Please don't recommend doing this..

I'm kind of curious why you wouldn't want people doing this.  When we
were developing our solution based on LIO target we encountered this
exact problem and hacked together a bandaid:

https://github.com/agrover/targetcli-fb/issues/1

In the end we wrote our own perl bindings that manipulate the configfs
directly for a few reasons:

- Issues with interpreting success/failure on targetcli as mentioned
above
- Inability to set everything via the shell (ex: vpd-unit-serial)
- Slow performance of the shell at large scale of exports (10 minute
save/restore with thousands of targets)
- We wanted perl, not python

We figured that since targetcli was really just a wrapper around the
config filesystem we could do what it was doing and do it much faster.
Aside from input validation is there a pitfall that we might walk into
here?

> > 2) If using Python, using rtslib library
> > 
> Yes, this is what most folks probably want to end up doing.

Unless they're a perl shop.  ;)

> > if using targetcli-fb:
> > 
> > 3) reading/modifying/writing /etc/target/saveconfig.json then reloading 
> > config
> 
> Ugh..

Seconded, but we considered it.
> 
> > 4) cmdline invocation with that patch you referenced
> > 
> > with another possibility of course being:
> > 
> > 5) Fix targetcli
> > 
> 
> FYI, we're now in the process of reconciling the upstream
> rtslib/configshell/targetcli trees with -fb, and avoiding the stuff that
> was included to -fb with no community review.

There are several real improvements to the targetcli-fb branch that I
hope aren't lost in the reconciliation.  For a period of time the -fb
branch was the faster, more usable one for our purposes.

--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux