Open Stack

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:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev