Open Stack

On Oct 14, 2014, at 1:12 PM, Clint Byrum <clint at fewbar.com> 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.

If this is how people are going to use and think about containers, I would
submit they are a huge waste of time. The performance value they offer is
dramatically outweighed by the flexibilty and existing tooling that exists
for virtual machines. As I state in my blog post[1] if we really want to
get value from containers, we must convert to the single application per
container view. This means having standard ways of doing the above either
on the host machine or in a debugging container that is as easy (or easier)
than the workflow you mention. There are not good ways to do this yet, and
the community hand-waves it away, saying things like, "well you could …”.
You could isn’t good enough. The result is that a lot of people that are
using containers today are doing fat containers with a full os.

Vish

[1] https://medium.com/@vishvananda/standard-components-not-standard-containers-c30567f23da6
> 
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141015/42bd4984/attachment.pgp>