Thanks Sylvain, we did not work out the API requirement till now but I
think the requirement should be similar with nova: we need
select_destination to select the best target host based on filters and
weights.

There are also some discussions here
https://blueprints.launchpad.net/magnum/+spec/magnum-scheduler-for-docker

Thanks!

2015-02-09 16:22 GMT+08:00 Sylvain Bauza <sba...@redhat.com>:

>  Hi Magnum team,
>
>
> Le 07/02/2015 19:24, Steven Dake (stdake) a écrit :
>
>
>
>   From: Eric Windisch <e...@windisch.us>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Saturday, February 7, 2015 at 10:09 AM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Magnum] Scheduling for Magnum
>
>
>> 1) Cherry pick scheduler code from Nova, which already has a working a
>> filter scheduler design.
>>
>
> The Gantt team explored that option by the Icehouse cycle and it failed
> with a lot of problems. I won't list all of those, but I'll just explain
> that we discovered how the Scheduler and the Nova compute manager were
> tighly coupled, which was meaning that a repository fork was really
> difficult to do without reducing the tech debt.
>
> That said, our concerns were far different from the Magnum team : it was
> about having feature parity and replacing the current Nova scheduler, while
> your team is just saying that they want to have something about containers.
>
>
>     2) Integrate swarmd to leverage its scheduler[2].
>
>
>  I see #2 as not an alternative but possibly an "also". Swarm uses the
> Docker API, although they're only about 75% compatible at the moment.
> Ideally, the Docker backend would work with both single docker hosts and
> clusters of Docker machines powered by Swarm. It would be nice, however, if
> scheduler hints could be passed from Magnum to Swarm.
>
>  Regards,
> Eric Windisch
>
>
>  Adrian & Eric,
>
>  I would prefer to keep things simple and just integrate directly with
> swarm and leave out any cherry-picking from Nova. It would be better to
> integrate scheduling hints into Swarm, but I’m sure the swarm upstream is
> busy with requests and this may be difficult to achieve.
>
>
> I don't want to give my opinion about which option you should take as I
> don't really know your needs. If I understand correctly, this is about
> having a scheduler providing affinity rules for containers. Do you have a
> document explaining which interfaces you're looking for, which kind of APIs
> you're wanting or what's missing with the current Nova scheduler ?
>
> MHO is that the technology shouldn't drive your decision : whatever the
> backend is (swarmd or an inherited nova scheduler), your interfaces should
> be the same.
>
> -Sylvain
>
>
>   Regards
> -steve
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to