Kevin, 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.
Erlon On Sat, Oct 8, 2016 at 12:14 AM, Zhenyu Zheng <zhengzhenyul...@gmail.com> wrote: > So do we like the idea of "volume based scheduling?" > > On Tue, Sep 27, 2016 at 11:39 AM, Joshua Harlow <harlo...@fastmail.com> > wrote: > >> Huang Zhiteng wrote: >> >>> >>> >>> On Tue, Sep 27, 2016 at 12:00 AM, Joshua Harlow <harlo...@fastmail.com >>> <mailto:harlo...@fastmail.com>> wrote: >>> >>> Huang Zhiteng wrote: >>> >>> >>> On Mon, Sep 26, 2016 at 12:05 PM, Joshua Harlow >>> <harlo...@fastmail.com <mailto:harlo...@fastmail.com> >>> <mailto:harlo...@fastmail.com <mailto:harlo...@fastmail.com>>> >>> >>> wrote: >>> >>> Huang Zhiteng wrote: >>> >>> In eBay, we did some inhouse change to Nova so that our >>> big data >>> type of >>> use case can have physical disks as ephemeral disk for >>> this type of >>> flavors. It works well so far. My 2 cents. >>> >>> >>> Is there a published patch (or patchset) anywhere that >>> people can >>> look at for said in-house changes? >>> >>> >>> Unfortunately no, but I think we can publish it if there are >>> enough >>> interests. However, I don't think that can be easily adopted >>> onto >>> upstream Nova since it depends on other in-house changes we've >>> done to Nova. >>> >>> >>> Is there any blog, or other that explains the full bunch of changes >>> that ebay has done (u got me curious)? >>> >>> The nice thing about OSS is that if u just get the patchsets out >>> (even to github or somewhere), those patches may trigger things to >>> change to match your usecase better just by the nature of people >>> being able to read them; but if they are never put out there, then >>> well ya, it's a little hard to get anything to change. >>> >>> >>> Anything stopping a full release of all in-house changes? >>> >>> Even if they are not 'super great quality' it really doesn't matter >>> :) >>> >>> Apology for sidetracking the topic a bit. While we encourage our >>> engineers to embrace community and open source, I think we didn't do a >>> good job to actually emphasize that. 'Time To Market' is another factor, >>> usually a feature requirement becomes deployed service in 2,3 sprint >>> (4~6 weeks), but you know how much can be done in same amount of time in >>> community, especially with Nova. :) >>> >> >> Ya, sorry for side-tracking, >> >> 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 :) >> >> https://lwn.net/Articles/647524/ (replace embedded linux/kernel in this >> with openstack and imho it's equally useful/relevant). >> >> >> -Josh >> >> >> >> >> >> >> ____________________________________________________________ >> ______________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib >> e >> http://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 > >
__________________________________________________________________________ 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