Open Stack

On 10/14/2014 01:12 PM, Clint Byrum wrote:
> Excerpts from Lars Kellogg-Stedman's message of 2014-10-14 12:50:48 -0700:
>> On Tue, Oct 14, 2014 at 03:25:56PM -0400, Jay Pipes wrote:
>>> I think the above strategy is spot on. Unfortunately, that's not how the
>>> Docker ecosystem works.
>> I'm not sure I agree here, but again nobody is forcing you to use this
>> tool.
>>
>>> operating system that the image is built for. I see you didn't respond to my
>>> point that in your openstack-containers environment, you end up with Debian
>>> *and* Fedora images, since you use the "official" MySQL dockerhub image. And
>>> therefore you will end up needing to know sysadmin specifics (such as how
>>> network interfaces are set up) on multiple operating system distributions.
>> I missed that part, but ideally you don't *care* about the
>> distribution in use.  All you care about is the application.  Your
>> container environment (docker itself, or maybe a higher level
>> abstraction) sets up networking for you, and away you go.
>>
>> If you have to perform system administration tasks inside your
>> containers, my general feeling is that something is wrong.
>>
> Speaking as a curmudgeon ops guy from "back in the day".. the reason
> I choose the OS I do is precisely because it helps me _when something
> is wrong_. And the best way an OS can help me is to provide excellent
> debugging tools, and otherwise move out of the way.
>
> When something _is_ wrong and I want to attach GDB to mysqld in said
> container, I could build a new container with debugging tools installed,
> but that may lose the very system state that I'm debugging. So I need to
> run things inside the container like apt-get or yum to install GDB.. and
> at some point you start to realize that having a whole OS is actually a
> good thing even if it means needing to think about a few more things up
> front, such as "which OS will I use?" and "what tools do I need installed
> in my containers?"
>
> What I mean to say is, just grabbing off the shelf has unstated
> consequences.
The biggest gain of containers is they are hermetically sealed. They 
turn hundreds of packages (the dependencies and OS files) into 1 
interface with one operation:
Start with a defined variatic environment.

This idea rocks if you can put up with the pain that debugging something 
that is busted is very difficult.   Accessing logs is not tidy and 
debugging in the ways that true experienced folk know how to (with gdb 
attach for example) just isn't possible.

It also requires that you rely on a completely stateless model (until 
persistent storage is implemented in k8s I guess) and completely 
idempotent model.  I really like the idea of "time to upgrade, lets roll 
new images across the cluster".  This model is very powerful but comes 
with some pain.

Regards
-steve


>>> Sure, Docker isn't any more limiting than using a VM or bare hardware, but
>>> if you use the "official" Docker images, it is more limiting, no?
>> No more so than grabbing a virtual appliance rather than building a
>> system yourself.
>>
>> In other words: sure, it's less flexible, but possibly it's faster to
>> get started, which is especially useful if your primary goal is not
>> "be a database administrator" but is actually "write an application
>> that uses a database backend".
>>
>> I think there are uses cases for both "official" and customized
>> images.
>>
> In the case of Kolla, we're deploying OpenStack, not just some new
> application that uses a database backend. I think the bar is a bit
> higher for operations than end-user applications, since it sits below
> the abstractions, much closer to the metal.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev