On Fri, 2013-10-11 at 17:10 -0600, Tregaron Bayly wrote: > 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. For two reasons primarily: 1) rtslib is 'future proofed' in such a way that new fabric modules work without requiring any user-space changes. Alot of time and effort went in to making things work this way, so unless code poking at configfs takes this into account, it's likely that it will have to change every time a new fabric module is added. 2) There are specific ordering requirements of how setup + teardown works in configfs, and rtslib abstracts this away from the consumer. For example, explicitly disabling an endpoint to force the shutdown of all active sessions, before tearing down the LUNs, etc. > 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) This can still be set via rtslib, no..? > - Slow performance of the shell at large scale of exports (10 minute > save/restore with thousands of targets) So what's the bottleneck here..? Python execution performace, or something else..? > - 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? > See above. ;) > > > 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. > There are many improvements in -fb no doubt, and we'll end up absorbing all of those that are worthwhile and correct. --nab -- 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
