Open Stack

Steve,

So you mean we should focus on docker and k8s scheduler? I was a bit
confused, why do we need to care k8s? As the k8s cluster was created by
heat and once the k8s was created, the k8s has its own scheduler for
creating pods/service/rcs.

So seems we only need to care scheduler for native docker and ironic bay,
comments?

Thanks!

2015-02-10 12:32 GMT+08:00 Steven Dake (stdake) <stdake at cisco.com>:

>
>
>   From: Joe Gordon <joe.gordon0 at gmail.com>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: Monday, February 9, 2015 at 6:41 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [Magnum] Scheduling for Magnum
>
>
>
> On Mon, Feb 9, 2015 at 6:00 AM, Steven Dake (stdake) <stdake at cisco.com>
> wrote:
>
>>
>>
>> On 2/9/15, 3:02 AM, "Thierry Carrez" <thierry at openstack.org> wrote:
>>
>> >Adrian Otto wrote:
>> >> [...]
>> >> We have multiple options for solving this challenge. Here are a few:
>> >>
>> >> 1) Cherry pick scheduler code from Nova, which already has a working a
>> >>filter scheduler design.
>> >> 2) Integrate swarmd to leverage its scheduler[2].
>> >> 3) Wait for the Gantt, when Nova Scheduler to be moved out of Nova.
>> >>This is expected to happen about a year from now, possibly sooner.
>> >> 4) Write our own filter scheduler, inspired by Nova.
>> >
>> >I haven't looked enough into Swarm to answer that question myself, but
>> >how much would #2 tie Magnum to Docker containers ?
>> >
>> >There is value for Magnum to support other container engines / formats
>> >(think Rocket/Appc) in the long run, so we should avoid early design
>> >choices that would prevent such support in the future.
>>
>> Thierry,
>> Magnum has an object type of a bay which represents the underlying cluster
>> architecture used.  This could be kubernetes, raw docker, swarmd, or some
>> future invention.  This way Magnum can grow independently of the
>> underlying technology and provide a satisfactory user experience dealing
>> with the chaos that is the container development world :)
>>
>
>  While I don't disagree with anything said here, this does sound a lot
> like https://xkcd.com/927/
>
>
>
>     Andrew had suggested offering a unified standard user experience and
> API.  I think that matches the 927 comic pretty well.  I think we should
> offer each type of system using APIs that are similar in nature but that
> offer the native features of the system.  In other words, we will offer
> integration across the various container landscape with OpenStack.
>
>  We should strive to be conservative and pragmatic in our systems support
> and only support container schedulers and container managers that have
> become strongly emergent systems.  At this point that is docker and
> kubernetes.  Mesos might fit that definition as well.  Swarmd and rocket
> are not yet strongly emergent, but they show promise of becoming so.  As a
> result, they are clearly systems we should be thinking about for our
> roadmap.  All of these systems present very similar operational models.
>
>  At some point competition will choke off new system design placing an
> upper bound on the amount of systems we have to deal with.
>
>  Regards
> -steve
>
>
>
>> We will absolutely support relevant container technology, likely through
>> new Bay formats (which are really just heat templates).
>>
>> Regards
>> -steve
>>
>> >
>> >--
>> >Thierry Carrez (ttx)
>> >
>>
>> >__________________________________________________________________________
>> >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
>>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150210/6a62f426/attachment.html>