<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 09/24/2014 10:01 PM, Mike Spreitzer
wrote:<br>
</div>
<blockquote
cite="mid:OFE6F0E706.A2F0D134-ON85257D5E.0019DDB4-85257D5E.001BA380@us.ibm.com"
type="cite"><tt><font size="2">Clint Byrum
<a class="moz-txt-link-rfc2396E" href="mailto:clint@fewbar.com"><clint@fewbar.com></a> wrote on 09/25/2014
12:13:53 AM:<br>
<br>
> Excerpts from Mike Spreitzer's message of 2014-09-24
20:49:20 -0700:<br>
> > Steven Dake <a class="moz-txt-link-rfc2396E" href="mailto:sdake@redhat.com"><sdake@redhat.com></a> wrote on
09/24/2014 11:02:49
PM:</font></tt>
<br>
<tt><font size="2">> > > ...</font></tt>
<br>
<tt><font size="2">> > ...<br>
> > Does TripleO require container functionality that is
not available<br>
> > when using the Docker driver for Nova?<br>
> > <br>
> > As far as I can tell, the quantitative handling of
capacities
and<br>
> > demands in Kubernetes is much inferior to what Nova
does today.<br>
> > <br>
> <br>
> Yes, TripleO needs to manage baremetal and containers
from a single<br>
> host. Nova and Neutron do not offer this as a feature
unfortunately.</font></tt>
<br>
<br>
<tt><font size="2">In what sense would Kubernetes "manage
baremetal"
(at all)?</font></tt>
<br>
<tt><font size="2">By "from a single host" do you mean that
a client on one host</font></tt>
<br>
<tt><font size="2">can manage remote baremetal and containers?</font></tt>
<br>
<br>
<tt><font size="2">I can see that Kubernetes allows a client on
one host
to get</font></tt>
<br>
<tt><font size="2">containers placed remotely --- but so does the
Docker
driver for Nova.</font></tt>
<br>
<br>
<tt><font size="2">> <br>
> > > As far as use cases go, the main use case is to
run a specific
<br>
> > > Docker container on a specific Kubernetes
"minion"
bare metal host.</font></tt>
<br>
<br>
<tt><font size="2">Clint, in another branch of this email tree you
referred
to</font></tt>
<br>
<tt><font size="2">"the VMs that host Kubernetes". How
does that square with</font></tt>
<br>
<tt><font size="2">Steve's text that seems to imply bare metal
minions?</font></tt>
<br>
<tt><font size="2"><br>
I can see that some people have had much more detailed design</font></tt>
<br>
<tt><font size="2">discussions than I have yet found. Perhaps it
would be helpful</font></tt>
<br>
<tt><font size="2">to share an organized presentation of the
design thoughts
in</font></tt>
<br>
<tt><font size="2">more detail.</font></tt>
<br>
<br>
</blockquote>
<br>
Mike,<br>
<br>
I have had no such design discussions. Thus far the furthest along
we are in the project is determining we need Docker containers for
each of the OpenStack daemons. We are working a bit on how that
design should operate. For example, our current model on
reconfiguration of a docker container is to kill the docker
container and start a fresh one with the new configuration.<br>
<br>
This is literally where the design discussions have finished. We
have not had much discussion about Kubernetes at all other then I
know it is a docker scheduler and I know it can get the job done :)
I think other folks design discussions so far on this thread are
speculation about what an architecture should look like. That is
great - lets have those Monday 2000 UTC in #openstack-medeting in
our first Kolla meeting.<br>
<br>
Regards<br>
-steve<br>
<br>
<blockquote
cite="mid:OFE6F0E706.A2F0D134-ON85257D5E.0019DDB4-85257D5E.001BA380@us.ibm.com"
type="cite"><tt><font size="2">> > <br>
> > If TripleO already knows it wants to run a specific
Docker image<br>
> > on a specific host then TripleO does not need a
scheduler.<br>
> > <br>
> <br>
> TripleO does not ever specify destination host, because
Nova does
not<br>
> allow that, nor should it. It does want to isolate
failure domains
so<br>
> that all three Galera nodes aren't on the same PDU, but
we've not
really<br>
> gotten to the point where we can do that yet.</font></tt>
<br>
<br>
<tt><font size="2">So I am still not clear on what Steve is trying
to
say is the main use case.</font></tt>
<br>
<tt><font size="2">Kubernetes is even farther from balancing among
PDUs
than Nova is.</font></tt>
<br>
<tt><font size="2">At least Nova has a framework in which this
issue
can be posed and solved.</font></tt>
<br>
<tt><font size="2">I mean a framework that actually can carry the
necessary
information.</font></tt>
<br>
<tt><font size="2">The Kubernetes scheduler interface is extremely
impoverished
in the</font></tt>
<br>
<tt><font size="2">information it passes and it uses GO structs
--- which,
like C structs,</font></tt>
<br>
<tt><font size="2">can not be subclassed.</font></tt>
<br>
<tt><font size="2">Nova's filter scheduler includes a fatal bug
that
bites when balancing and you want more than</font></tt>
<br>
<tt><font size="2">one element per area, see </font></tt><a
moz-do-not-send="true"
href="https://bugs.launchpad.net/nova/+bug/1373478"><tt><font
size="2" color="blue">https://bugs.launchpad.net/nova/+bug/1373478</font></tt></a><tt><font
size="2">.</font></tt>
<br>
<tt><font size="2">However: (a) you might not need more than one
element
per area and</font></tt>
<br>
<tt><font size="2">(b) fixing that bug is a much smaller job than
expanding
the mind of K8s.</font></tt>
<br>
<tt><font size="2"><br>
Thanks,</font></tt>
<br>
<tt><font size="2">Mike</font></tt>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>