<div dir="ltr">Kevin,<div><br></div><div>Now that you had a first feedback about the idea, as Jay said, the next steps is to write a blueprint/spec so other folks in Cinder can better understand/suggest/vote on what you are proposing.</div><div><br></div><div><br></div><div>Erlon</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Oct 8, 2016 at 12:14 AM, Zhenyu Zheng <span dir="ltr"><<a href="mailto:zhengzhenyulixi@gmail.com" target="_blank">zhengzhenyulixi@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">So do we like the idea of "volume based scheduling?"</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Sep 27, 2016 at 11:39 AM, Joshua Harlow <span dir="ltr"><<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Huang Zhiteng wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
<br>
<br>
On Tue, Sep 27, 2016 at 12:00 AM, Joshua Harlow <<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a><br></span><span>
<mailto:<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>><wbr>> wrote:<br>
<br>
    Huang Zhiteng wrote:<br>
<br>
<br>
        On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow<br>
        <<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a> <mailto:<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>><br></span>
        <mailto:<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a> <mailto:<a href="mailto:harlowja@fastmail.com" target="_blank">harlowja@fastmail.com</a>><wbr>>><div><div class="m_4317197658758868708h5"><br>
        wrote:<br>
<br>
             Huang Zhiteng wrote:<br>
<br>
                 In eBay, we did some inhouse change to Nova so that our<br>
        big data<br>
                 type of<br>
                 use case can have physical disks as ephemeral disk for<br>
        this type of<br>
                 flavors.  It works well so far.   My 2 cents.<br>
<br>
<br>
             Is there a published patch (or patchset) anywhere that<br>
        people can<br>
             look at for said in-house changes?<br>
<br>
<br>
        Unfortunately no, but I think we can publish it if there are enough<br>
        interests.  However, I don't think that can be easily adopted onto<br>
        upstream Nova since it depends on other in-house changes we've<br>
        done to Nova.<br>
<br>
<br>
    Is there any blog, or other that explains the full bunch of changes<br>
    that ebay has done (u got me curious)?<br>
<br>
    The nice thing about OSS is that if u just get the patchsets out<br>
    (even to github or somewhere), those patches may trigger things to<br>
    change to match your usecase better just by the nature of people<br>
    being able to read them; but if they are never put out there, then<br>
    well ya, it's a little hard to get anything to change.<br>
<br>
<br>
    Anything stopping a full release of all in-house changes?<br>
<br>
    Even if they are not 'super great quality' it really doesn't matter :)<br>
<br>
Apology for sidetracking the topic a bit.  While we encourage our<br>
engineers to embrace community and open source, I think we didn't do a<br>
good job to actually emphasize that. 'Time To Market' is another factor,<br>
usually a feature requirement becomes deployed service in 2,3 sprint<br>
(4~6 weeks), but you know how much can be done in same amount of time in<br>
community, especially with Nova. :)<br>
</div></div></blockquote>
<br>
Ya, sorry for side-tracking,<br>
<br>
Overall yes I do know getting changes done in upstream is not a 4-6 week process (though maybe someday it could be). In general I don't want to turn this into a rant, and thankfully I think there is a decent LWN article about this kind of situation already. You might like it :)<br>
<br>
<a href="https://lwn.net/Articles/647524/" rel="noreferrer" target="_blank">https://lwn.net/Articles/64752<wbr>4/</a> (replace embedded linux/kernel in this with openstack and imho it's equally useful/relevant).<div class="m_4317197658758868708HOEnZb"><div class="m_4317197658758868708h5"><br>
<br>
-Josh<br>
<br>
<br>
<br>
<br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>