<br><br><div class="gmail_quote">On Wed, Nov 21, 2012 at 12:51 PM, Russell Bryant <span dir="ltr"><<a href="mailto:rbryant@redhat.com" target="_blank">rbryant@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 11/21/2012 02:15 PM, Huang Zhiteng wrote:<br>
> Hi,<br>
><br>
> I've been trying to port filter scheduler (as well as host_manager(),<br>
> host_state(), filters, cost functions stuff) from Nova to Cinder.<br>
> While we are trying to get the change to land in G1, Russell raised<br>
> point that since majority of the code is shared between Nova and<br>
> Cinder, then we should get filter scheduler into Olso. IMO, this is<br>
> doable but it may take more effort to refactor the scheduler to adopt<br>
> the need of two projects than simply porting.  From Cinder's<br>
> perspective, it really needs this feature to allow real/sophisticated<br>
> placement decision to be made in order to support board choice of<br>
> storage back-ends, due to the fact that chance/simple scheduler are<br>
> just toys.<br>
><br>
> If this is the right thing to do, let's discuss how should we do it<br>
> and make sure we can land it before G2 since we were targeting this<br>
> feature to G1 for Cinder.  Any thought/comment/suggestion?  Thanks.<br>
<br>
</div>I agree that it's going to take more work than just copying the code<br>
into oslo-incubator.  However, it's the right thing to do and no<br>
artificial deadline should be used to lower the quality of the work we do.<br>
<br>
The code in nova has already diverged from what is in the cinder patch.<br>
 If the code goes into cinder, that problem will only get worse and<br>
trying to reconcile the copied code will get more and more difficult.<br>
<br>
So let's focus on how we can make this happen and get it done ASAP.  :-)<br>
 I think the G2 time frame is doable, but it's going to take some pushing.<br>
<br>
We need to take a look at this and figure out what is common and what<br>
isn't.  Here's a start ...<br>
<br>
I think the easiest part is the filters, so:<br>
<br>
patch idea #1) move nova/loadables.py to oslo-inclubator<br>
<br>
patch idea #2) move base filter (nova/filters.py) to oslo-incubator<br>
<br>
patch ideas #3..N) host filter base code, shared host filters<br>
<br>
It looks like the base host filter code in<br>
nova/scheduler/filters/__init__.py is pretty generic already.  Then we<br>
can also move the host filters that are used by both cinder and nova.<br>
<br>
That would be a *great* start and would cut down quite a bit on the<br>
copied code.<br>
<br>
The next steps after that are looking at putting a base scheduler<br>
abstraction, and a base filter scheduler that could be shared between<br>
the two projects.  That's going to take more refactoring than what I<br>
outlined above.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Russell Bryant<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div>Russell,<div><br></div><div>I agree with all of your statements, but there is one thing I would like to point and clarify regarding deadline etc.  Currently we don't have ANY filter scheduling functionality in Cinder so it's not quite as "bake it til it's done" as we may like.  We also have features/bp's that rely on this (which is why it was initially targeted for G1).  So, I'd really like to see G2 at latest, the features that depend on it can be pushed out as well, but pushing them out of Grizzly altogether is not something I think is acceptable.  I don't think anything you said contradicted anything here, but I just wanted to be clear about where things are in terms of Cinder.</div>
<div><br></div><div>All of that being said, I think G2 is perfectly reasonable all the way around, assuming folks agree that it's a good idea to begin with.</div><div><br></div><div>John</div>