On 01/18/2015 11:02 PM, Steven Dake wrote:
On 01/18/2015 07:59 PM, Jay Pipes wrote:
On 01/18/2015 11:11 AM, Steven Dake wrote:
On 01/18/2015 06:39 AM, Jay Lau wrote:
Thanks Steven, just some questions/comments here:
1) For native docker support, do we have some project to handle the
network? The current native docker support did not have any logic for
network management, are we going to leverage neutron or nova-network
just like nova-docker for this?
We can just use flannel for both these use cases. One way to approach
using flannel is that we can expect docker networks will always be setup
the same way, connecting into a flannel network.
Note that the README on the Magnum GH repository states that one of
the features of Magnum is its use of Neutron:
"Integration with Neutron for k8s multi-tenancy network security."
Is this not true?
Jay,
We do integrate today with Neutron for multi-tenant network security.
Flannel runs on top of Neutron networks using vxlan. Neutron provides
multi-tenant security; Flannel provides container networking. Together,
they solve the multi-tenant container networking problem in a secure way.
Gotcha. That makes sense, now.
Its a shame these two technologies can't be merged at this time, but we
will roll with it until someone invents an integration.
2) For k8s, swarm, we can leverage the scheduler in those container
management tools, but what about docker native support? How to handle
resource scheduling for native docker containers?
I am not clear on how to handle native Docker scheduling if a bay has
more then one node. I keep hoping someone in the community will propose
something that doesn't introduce an agent dependency in the OS.
So, perhaps because I've not been able to find any documentation for
Magnum besides the README (the link to developers docs is a 404), I
have quite a bit of confusion around what value Magnum brings to the
OpenStack ecosystem versus a tenant just installing Kubernetes on one
of more of their VMs and managing container resources using k8s directly.
Agree documentation is dearth at this point. The only thing we really
have at this time is the developer guide here:
https://github.com/stackforge/magnum/blob/master/doc/source/dev/dev-quickstart.rst
Installing Kubernetes in one or more of their VMs would also work with
kubernetes. In fact, you can do this easily today with larsks
heat-kubernetes Heat template which we shamelessly borrowed without
magnum at all.
We do intend to offer bare metal deployment of kubernetes as well, which
should offer a significant I/O performance advantage, which is after all
what cloud services are all about.
Of course someone could just deploy kubernetes themselves on bare metal,
but there isn't at this time an integrated tool to provide
"Kubernetes-installation-as-a-service" endpoint. Magnum does that job
today right now on master. I suspect it can and will do more as we get
past our 2 month mark of development ;)
Ha! No worries, Steven. :) Heck, I have enough trouble just keeping up
with the firehose of information about new container-related stuffs that
I'm well impressed with the progress that the container team has made so
far. I just wish I had ten more hours a day to read and research more on
the topic!
Is the goal of Magnum to basically be like Trove is for databases and
be a Kubernetes-installation-as-a-Service endpoint?
I believe that is how the project vision started out. I'm not clear on
the long term roadmap - I suspect there is alot more value that can be
added in. Some of these things, like manually or automatically scaling
the infrastructure show some of our future plans. I'd appreciate your
suggestions.
Well, when I wrap my brain around more of the container technology, I
will certainly try and provide some feedback! :)
Best,
-jay
Thanks in advance for more info on the project. I'm genuinely curious.
Always a pleasure,
-steve
Best,
-jay
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
