Open Stack

On 11/27/2012 10:51 AM, Eric Harney wrote:
> I hadn't considered the dual approach idea before -- do we think it
> would be beneficial?  I'm not convinced it would be much quicker, since
> we likely have to do some amount of work to fix targetcli.  (See below.)
> 
>>> I think the "simple" driver using targetcli would fit the current cinder
>>> model fairly well.  It would essentially just plug another class into
>>> the abstraction between TgtAdm and IetAdm provided by
>>> get_target_admin().
>>
>> IIRC, targetcli doesn't provide any usable way to detect errors (return
>> codes or pareseable output).  If I'm wrong, or if we can help improve
>> that, that sounds ok to me.
>>
> 
> Yes, this was the main issue I saw with using targetcli.  It seems to be
> designed mostly for interactive use.

It is designed entirely for interactive use. Local programmatic
configuration should be done via rtslib. Remote programmatic
configuration should be done via targetd.

If neither of these is really an option, I'd actually prefer you write a
custom executable wrapper around rtslib that does what you need. This
will also avoid pulling in the dependencies needed for targetcli's
interactive capability.

I am of the opinion that using libraries is infinitely preferable to
shelling out to execute cmdline tools, see:

http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/09/Grover-APIs.odp

I certainly understand needing to do so for the many existing tools that
don't have libraries, but to force this model when proper APIs are
available (in Python, even) seems less than ideal.

Regards -- Andy