Open Stack

On Tue, Jan 7, 2014 at 6:45 PM, Clint Byrum <clint at fewbar.com> wrote:
> Excerpts from James Slagle's message of 2014-01-07 15:03:33 -0800:
>> On Tue, Jan 7, 2014 at 5:18 PM, Clint Byrum <clint at fewbar.com> wrote:
>> > Excerpts from James Slagle's message of 2014-01-07 12:53:57 -0800:
>> >> On Tue, Jan 7, 2014 at 3:23 PM, Clint Byrum <clint at fewbar.com> wrote:

> Image proliferation is far easier to measure than package proliferation.
> But, that is not really the point.

If you're managing it right, you don't have package proliferation, any
more than you do image proliferation.  But, if that's no longer the
point, then we can move on :).

> The point is that we have a tool for software distribution that fits into
> our system management approach, and the distro packages do not take that
> system management approach into account.
>
> So if you can't use the distro packages as-is, I'm questioning what the
> actual benefit of using them at all is.

Well, I can't argue that if we install from packages, and then have to
hack up the installed files to make them work with our approach, that
is not ideal and not really sane. Personally, it would be great if the
distro packages had support for the image based approach.  And truly,
if OpenStack is adopting the image based installation and deployment
mechanism as "the way", then the Installation guide isn't even going
to say install from packages anymore on top of your base OS.  It's
just going to be all TripleO.  And, I think the distros would have to
adapt to that.

I don't honestly know how much you could use the current distro
packages as-is.  But, I'm sure I'll find out soon enough.

>
>> >
>> >> > We've specifically avoided packages because they complect[1] configuration
>> >> > and system state management with software delivery. The recent friction
>> >> > we've seen with MySQL is an example where the packages are not actually
>> >> > helping us, they're hurting us because they encode too much configuration
>> >> > instead of just delivering binaries.
>> >>
>> >> We're trying to do something fairly specific with the read only /
>> >> partition.  You're right, most packages aren't going to handle that
>> >> well.  So, yes you have a point from that perspective.
>> >>
>> >
>> > Readonly / is a really important feature of the deployment we're aiming
>> > at. Doing it with packages is quite possible. My point in asking why
>> > bother with packages is that when you have an entire image that has been
>> > verified and is known to work, what advantage does having a package for
>> > everything actually bring.
>>
>> Because distro packages are known to work, and thus you get higher
>> confidence from any image constructed from said packages.  At least, I
>> would, as opposed to installing from source (or "from git" as you say
>> below :).  It's the same reason I want to use a packaged kernel
>> instead of compiling it from source.  The benefit of the package is
>> not just in the compiling.  It's in the known good version and
>> compatibility with other known good versions I want to use.
>>
>
> I would disagree with "known to work". They are known to have been
> tested at some level. But IMO "known to work" requires testing _with
> your workload_.

So this is just semantics around "known to work".  Definitely you have
to test in your own environment before deploying anything.  I more
meant "known to be compatible", "known to be supported", "known to
work on certain hardware".  Or "advertised to".  Things of that
nature. But, none of those imply you don't test.

Also, the inverse can be equally valuable.  These versions do *not*
work on this hardware, etc.

> Since you have to test your workload, why bother with the distro packages
> when you can get the upstream software and testing suite directly.
>
>> Am I going to implicitly trust any packages blindly or completely?  Of
>> course not. But, there is some confidence there in that the distro has
>> done some testing and said these versions are compatible, etc.
>>
>
> I think that confidence is misplaced and unnecessary.

Certainly if you set the expectation that that nothing is "known to
work", then no one is going to have any confidence that it does.
OpenStack does releases of projects that are in some form of a known
good state.  I would think most people would reasonably expect that
downloading that release would likely work better vs. grabbing from
git 2 weeks into a new development cycle.

Meaning, I have some confidence that OpenStack as a community has done
some testing.  We have qa, gates, unit and functional tests, etc.  I
don't think that confidence is misplaced or unnecessary.

If a distro says a set of OpenStack packages work with a given version
of their OS, then that confidence is not misplaced either IMO.

> We provide test
> suites to users and we will encourage users to test their own things. I
> imagine some will also ship packaged products based on TripleO that will
> also be tested as a whole, not as individual packages.

This is a new and rather orthogonal point.  I'm not talking about
testing individual packages.  You're right, that makes little sense.
The context is about testing the deployed image as a whole, and the
set of packages that are advertised or purported  to work together to
make the image work.  I don't think any distro says "hi, we've tested
these 1,000 packages individually, but not running together, come use
our stuff".

> We can stop all of those things with or without packages. My point isn't
> to say packages are harmful in an image-build-only context, it is to
> say that I don't see the benefit.

Other benefits have been mentioned in the thread, I won't rehash.

> I think you're basically saying they're worth complexity because somebody
> else tests them for you. I disagree, but I definitely would understand
> if people said I sound crazy and still want those packages.

I didn't say that at all.  Merely that a set of packages that are
advertised to work on a given OS version and are supported add
benefit.

In fact, I don't think they really add that much complexity compared
to what installing from git does.

-- 
-- James Slagle
--