Open Stack

On Tue, 2012-11-27 at 12:41 -0500, Russell Bryant wrote:
> On 11/27/2012 11:38 AM, Christoph Hellwig wrote:
> > On Tue, Nov 27, 2012 at 08:12:59AM -0800, Vishvananda Ishaya wrote:
> >> for this. It seems like the fastest path to using LIO would be to simply
> >> extend the tgt code to be able to use targetcli[1] in addition to tgtadmin
> >> and ietadmin. That seems like literally a few days of work.
> >>
> >> Integrating targetd sounds more complicated and I think it would be better
> >> done with its own driver. If you are managing volumes remotely I don't think you
> >> are going to get much benefit out of sharing the existing target code.
> >>
> >> Would you consider a dual approach? A quick-and-dirty version using targetcli
> >> to get lio support in, followed by a more general driver using targetd?
> > 

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.

> > The way I understand targetd (and Andy may have to correct me) it
> > actually managed the backend storage using e.g. LVM as well.
> 
> Agreed that it seems to make more sense for targetd to be its own Cinder
> driver.
> 

This is ok with me.