Open Stack

On Fri, Jul 25, 2014 at 10:43 AM, James Slagle <james.slagle at gmail.com>
wrote:

> On Fri, Jul 25, 2014 at 9:59 AM, John Griffith
> <john.griffith at solidfire.com> wrote:
>
> > The LIO versus Tgt thing however is a bit troubling.  Is there a reason
> that
> > TripleO decided to do the exact opposite of what the defaults are in the
> > rest of OpenStack here?  Also any reason why if there was a valid
> > justification for this it didn't seem like it might be worthwhile to work
> > with the rest of the OpenStack community and share what they considered
> to
> > be the better solution here?
>
> Not really following what you find troubling. Cinder allows you to
> configure it to use Tgt or LIO. Are you objecting to the fact that
> TripleO allows people to *choose* to use LIO?
>
​Nope, that's fine... what I'm uneasy about is there appears to be a
suggestion to have different defaults for things based on distribution.  If
this turns out to be the only way to make things work, then sure... we do
what we have to do.

Maybe I'm missing some points in the thread, if it's strictly "do we allow
options" then sure, I'm not saying that's a bad thing particularly if those
options are the same as we already do in other projects.

>> LIO is used on RHEL, because RHEL doesn't offer TGT. So what is "the LIO
>> versus Tgt thing?

What version of RHEL don't offer tgtadm?  It's in 6.5; also I responded to
a post on this subject a while back about having consistent defaults
whether you're dealing with an over-cloud or an under-cloud; IMO uniqueness
between the two in terms of defaults is something that should be carefully
weighed.  My suggestion was and is, that if for example LIO was the only
option, then we should work together to make that a consistent default
across the board.  Sounds like maybe I misunderstood what was being done
here so perhaps it's not an issue.

>> "TripleO is a program aimed at installing, upgrading and operating
>> OpenStack clouds using OpenStack's own cloud facilities as the
foundations
>> - building on nova, neutron and heat to automate fleet management at
>> datacentre scale (and scaling down to as few as 2 machines)."

Sure, but for some crazy reason I had always assumed that there would be
some 'value add' here, whether that be efficiency, ease of deployment or
whatever.  Not just "I can use OpenStack to deploy OpenStack and throw away
the large number of tools designed to do this sort of thing and reinvent
them because it's neat".

I'm not saying that's how I see it, but I am saying maybe the stated
purpose could use a bit of detail.

>> Nobody expects datacenter scale to be easy. We do, however, have a
>> reasonable expectation that OpenStack can be used to deploy large,
>> complex applications. If it cannot, OpenStack is in trouble.

Sure... but I think by adding (more to the point exposing) as much
complexity as possible and reinventing tools OpenStack will be in trouble
as well (likely more trouble).

Granted Heat is great for the deployment of applications in an OpenStack
Cloud, so you're saying that since TripleO uses Heat it falls into the same
category?  OpenStack on OpenStack is just another application we're
deploying?  Then maybe all of this should be folded in to Heat in perhaps a
different design, or maybe it already is for the most part.  Can't really
tell for sure as I've never really been able to do get anything really
working with TripleO as of yet, which goes back to my earlier comment about
complexity and what the actual goal is.


> As was explained in the review[1], Tgt is the default for TripleO. If
> you want to use LIO, TripleO offers that choice, just like Cinder
> does.
>

​Cool... you can disregard any comments I made on that subject then.
​

>
> [1] https://review.openstack.org/#/c/78463/
>
>
> --
> -- James Slagle
> --
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140725/3079bea6/attachment.html>