<div dir="ltr">Alex,<div><br></div><div>(*sorry for long reply from vocation*)</div><div><br></div><div><font face="sans-serif" style="font-size:13px">>> How do you envision the life cycle of such a scheduler in terms of code repository, build, test, etc?</font><span style="font-family:arial,sans-serif;font-size:13px"> </span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">As a first step we could just make it inside nova, when we finish and prove that this approach works well we could split it out the nova in separated project and integrate with devstack and so on so on...</font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="sans-serif" style="font-size:13px">>> What kind of changes to provisioning APIs do you envision to 'feed' such a scheduler?</font><span style="font-family:arial,sans-serif;font-size:13px"> </span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">At this moment nova.scheduler is already separated service with amqp queue, what we need at this moment is to add 1 new rpc method to it. That will update state of some host. </font></div>
<div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="sans-serif" style="font-size:13px">>> Any particular reason you didn't mention Neutron?</font><span style="font-family:arial,sans-serif;font-size:13px"> </span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">Yes, I am not familiar with Neutron architecture =)</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="sans-serif" style="font-size:13px">>> Also, there are some interesting technical challenges (e.g., state management across potentially large number of instances of memcached).</font><span style="font-family:arial,sans-serif;font-size:13px"> </span><br style="font-family:arial,sans-serif;font-size:13px">
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><font face="arial, sans-serif">10-100k keys-values is nothing for memcached. So what kind of instances?</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif">Best regards,</font></div><div><font face="arial, sans-serif">Boris Pavlovic</font></div><div><font face="arial, sans-serif"><br>
</font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div><div><font face="arial, sans-serif"><br></font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Sun, Nov 10, 2013 at 4:20 PM, Alex Glikson <span dir="ltr"><<a href="mailto:GLIKSON@il.ibm.com" target="_blank">GLIKSON@il.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<font face="sans-serif">Hi Boris,</font>
<br>
<br><font face="sans-serif">This is a very interesting approach.</font>
<br><font face="sans-serif">How do you envision the life cycle of
such a scheduler in terms of code repository, build, test, etc?</font>
<br><font face="sans-serif">What kind of changes to provisioning
APIs do you envision to 'feed' such a scheduler?</font>
<br><font face="sans-serif">Any particular reason you didn't mention
Neutron?</font>
<br><font face="sans-serif">Also, there are some interesting technical
challenges (e.g., state management across potentially large number of instances
of memcached).</font>
<br>
<br><font face="sans-serif">Thanks,</font>
<br><font face="sans-serif">Alex</font>
<br>
<br>
<br><tt><font>Boris Pavlovic <<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>> wrote
on 10/11/2013 07:05:42 PM:<br>
<br>
> From: Boris Pavlovic <<a href="mailto:bpavlovic@mirantis.com" target="_blank">bpavlovic@mirantis.com</a>></font></tt>
<br><tt><font>> To: "OpenStack Development Mailing List
(not for usage questions)" <br>
> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </font></tt>
<br><tt><font>> Date: 10/11/2013 07:07 PM</font></tt>
<br><tt><font>> Subject: Re: [openstack-dev] [nova][cinder][oslo][scheduler]
How to <br>
> leverage oslo schduler/filters for nova and cinder</font></tt>
<br><div class="HOEnZb"><div class="h5"><tt><font>> <br>
> Jay, </font></tt>
<br><tt><font>> <br>
> Hi Jay, yes we were working about putting all common stuff in oslo-<br>
> scheduler. (not only filters)</font></tt>
<br><tt><font>> <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.</font></tt>
<br><tt><font>> <br>
> To implement such approach we should change a bit current architecture: </font></tt>
<br><tt><font>> 1) Scheduler should store all his data (not nova.db
& cinder.db)</font></tt>
<br><tt><font>> 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) </font></tt>
<br><tt><font>> 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). </font></tt>
<br><tt><font>> 4) Drop cinder, and nova tables that store host
states (as we don't <br>
> need them) </font></tt>
<br><tt><font>> <br>
> We implemented already base start (mechanism that store snapshot of
<br>
> world state & sync it between different schedulers): </font></tt>
<br><tt><font>> <br>
> </font></tt><a href="https://review.openstack.org/#/c/45867/" target="_blank"><tt><font>https://review.openstack.org/#/c/45867/</font></tt></a><tt><font>
(it is still bit in WIP)</font></tt>
<br><tt><font>> <br>
> Best regards, </font></tt>
<br><tt><font>> Boris Pavlovic</font></tt>
<br><tt><font>> ---</font></tt>
<br><tt><font>> Mirantis Inc. </font></tt>
<br><tt><font>> <br>
> <br>
</font></tt>
<br><tt><font>> On Sun, Nov 10, 2013 at 1:59 PM, Jay Lau <<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>>
wrote:</font></tt>
<br><tt><font>> 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" target="_blank"><tt><font>https://blueprints.launchpad.net/oslo/+spec/oslo-scheduler</font></tt></a><tt><font><br>
</font></tt>
<br><tt><font>> Thanks,<br>
</font></tt>
<br><tt><font>> Jay<br>
</font></tt>
<br><tt><font>> <br>
</font></tt>
<br><tt><font>> 2013/11/9 Jay Lau <<a href="mailto:jay.lau.513@gmail.com" target="_blank">jay.lau.513@gmail.com</a>></font></tt>
<br><tt><font>> Greetings,</font></tt>
<br><tt><font>> <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.</font></tt>
<br><tt><font>> <br>
> Found some problems as following:</font></tt>
<br><tt><font>> 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.</font></tt>
<br><tt><font>> 2) Nova is not using filter/weight from oslo
and also not using <br>
> entry point to handle all filter/weight.</font></tt>
<br><tt><font>> 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.</font></tt>
<br><tt><font>> <br>
> So my proposal is as following:</font></tt>
<br><tt><font>> 1) Add more filters to oslo, such as same host
filter, different <br>
> host filter, retry filter etc.</font></tt>
<br><tt><font>> 2) Move all filters/weight logic in cinder from
cinder/scheduler to <br>
> cinder/openstack/common/scheduler</font></tt>
<br><tt><font>> 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.</font></tt>
<br><tt><font>> <br>
> Comments?</font></tt>
<br><tt><font>> <br>
> Thanks,</font></tt>
<br><tt><font>> <br>
> Jay</font></tt>
<br><tt><font>> <br>
> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
</font></tt>
<br><tt><font>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank"><tt><font>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font><br>
</font></tt></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>