<tt><font size=2>Clint Byrum <clint@fewbar.com> 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 <sdake@redhat.com> 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><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 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>