<tt><font size=2>Boris Pavlovic <bpavlovic@mirantis.com> wrote on
15/11/2013 05:57:20 PM:<br>
<br>
> >> How do you envision the life cycle of such a scheduler in
terms <br>
> of code repository, build, test, etc? </font></tt>
<br><tt><font size=2>> <br>
> As a first step we could just make it inside nova, when we finish
<br>
> and prove that this approach works well we could split it out the
<br>
> nova in separated project and integrate with devstack and so on so
on...</font></tt>
<br>
<br><tt><font size=2>So, Cinder (as well as Neutron, and potentially others)
would need to be hooked to Nova rpc?</font></tt>
<br>
<br><tt><font size=2>> >> What kind of changes to provisioning
APIs do you envision to <br>
> 'feed' such a scheduler? </font></tt>
<br><tt><font size=2>> <br>
> At this moment nova.scheduler is already separated service with amqp<br>
> queue, what we need at this moment is to add 1 new rpc method to it.<br>
> That will update state of some host. </font></tt>
<br>
<br><tt><font size=2>I was referring to external (REST) APIs. E.g., to
specify affinity.</font></tt>
<br>
<br><tt><font size=2>> >> Also, there are some interesting technical
challenges (e.g., <br>
> state management across potentially large number of instances of memcached). </font></tt>
<br><tt><font size=2>> <br>
> 10-100k keys-values is nothing for memcached. So what kind of instances?</font></tt>
<br>
<br><tt><font size=2>Instances of memcached. In an environment with multiple
schedulers. I think you mentioned that if we have, say, 10 schedulers,
we will also have 10 instances of memcached.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Alex</font></tt>
<br>
<br><tt><font size=2>> Best regards,</font></tt>
<br><tt><font size=2>> Boris Pavlovic</font></tt>
<br><tt><font size=2>> <br>
> <br>
</font></tt>
<br><tt><font size=2>> On Sun, Nov 10, 2013 at 4:20 PM, Alex Glikson
<GLIKSON@il.ibm.com> wrote:</font></tt>
<br><tt><font size=2>> Hi Boris, <br>
> <br>
> This is a very interesting approach. <br>
> How do you envision the life cycle of such a scheduler in terms of
<br>
> code repository, build, test, etc? <br>
> What kind of changes to provisioning APIs do you envision to 'feed'
<br>
> such a scheduler? <br>
> Any particular reason you didn't mention Neutron? <br>
> Also, there are some interesting technical challenges (e.g., state
<br>
> management across potentially large number of instances of memcached).
<br>
> <br>
> Thanks, <br>
> Alex <br>
> <br>
> <br>
> Boris Pavlovic <bpavlovic@mirantis.com> wrote on 10/11/2013
07:05:42 PM:<br>
> <br>
> > From: Boris Pavlovic <bpavlovic@mirantis.com> <br>
> > To: "OpenStack Development Mailing List (not for usage questions)"
<br>
> > <openstack-dev@lists.openstack.org>, <br>
> > Date: 10/11/2013 07:07 PM <br>
> > Subject: Re: [openstack-dev] [nova][cinder][oslo][scheduler]
How to <br>
> > leverage oslo schduler/filters for nova and cinder </font></tt>
<br><tt><font size=2>> > <br>
> > Jay,  <br>
> > <br>
> > Hi Jay, yes we were working about putting all common stuff in
oslo-<br>
> > scheduler. (not only filters) <br>
> > <br>
> > As a result of this work we understood, that this is wrong approach.<br>
> > Because it makes result code very complex and unclear. And actually
<br>
> > we didn't find the way to put all common stuff inside oslo. Instead
<br>
> > of trying to make life too complex we found better approach.
<br>
> >  Implement scheduler aaS that can scale (current solution
has some <br>
> > scale issues) & store all data from nova, cinder & probably
other places. <br>
> > <br>
> > To implement such approach we should change a bit current architecture: 
<br>
> > 1) Scheduler should store all his data (not nova.db & cinder.db)
<br>
> > 2) Scheduler should always have own snapshot of "wold"
state, and <br>
> > sync it with another schedulers using something that is quite
fast <br>
> > (e.g. memcached)  <br>
> > 3) Merge schedulers rpc methods from nova & cinder in one
scheduler <br>
> > (it is possbile if we store all data from cinder & nova in
one sceduler).  <br>
> > 4) Drop cinder, and nova tables that store host states (as we
don't <br>
> > need them)  <br>
> > <br>
> > We implemented already base start (mechanism that store snapshot
of <br>
> > world state & sync it between different schedulers): 
<br>
> > <br>
> > </font></tt><a href=https://review.openstack.org/#/c/45867/><tt><font size=2>https://review.openstack.org/#/c/45867/</font></tt></a><tt><font size=2>
(it is still bit in WIP) <br>
> > <br>
> > Best regards,  <br>
> > Boris Pavlovic <br>
> > --- <br>
> > Mirantis Inc.  <br>
> > <br>
> > <br>
> <br>
> > On Sun, Nov 10, 2013 at 1:59 PM, Jay Lau <jay.lau.513@gmail.com>
wrote: <br>
> > I noticed that there is already a bp in oslo tracing what I want
to do: <br>
> > </font></tt><a href="https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler"><tt><font size=2>https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler</font></tt></a><tt><font size=2><br>
> <br>
> > Thanks,<br>
> <br>
> > Jay<br>
> <br>
> > <br>
> <br>
> > 2013/11/9 Jay Lau <jay.lau.513@gmail.com> <br>
> > Greetings, <br>
> > <br>
> > Now in oslo, we already put some scheduler filters/weights logic
<br>
> > there and cinder is using oslo scheduler filters/weights logic,
<br>
> > seems we want both nova&cinder use this logic in future.
<br>
> > <br>
> > Found some problems as following: <br>
> > 1) In cinder, some filters/weight logic reside in cinder/openstack/<br>
> > common/scheduler and some filter/weight logic in cinder/scheduler,
<br>
> > this is not consistent and also will make some cinder hackers
<br>
> > confused: where shall I put the scheduler filter/weight. <br>
> > 2) Nova is not using filter/weight from oslo and also not using
<br>
> > entry point to handle all filter/weight. <br>
> > 3) There is not enough filters in oslo, we may need to add more
<br>
> > there: such as same host filter, different host filter, retry
filter etc. <br>
> > <br>
> > So my proposal is as following: <br>
> > 1) Add more filters to oslo, such as same host filter, different
<br>
> > host filter, retry filter etc. <br>
> > 2) Move all filters/weight logic in cinder from cinder/scheduler
to <br>
> > cinder/openstack/common/scheduler <br>
> > 3) Enable nova use filter/weight logic from oslo (Move all filter
<br>
> > logic to nova/openstack/common/scheduler) and also use entry
point <br>
> > to handle all filters/weight logic. <br>
> > <br>
> > Comments? <br>
> > <br>
> > Thanks, <br>
> > <br>
> > Jay <br>
> > <br>
> > <br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
> <br>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > OpenStack-dev@lists.openstack.org<br>
> > </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a>
<br><tt><font size=2>> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>
<br><tt><font size=2>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>