On Thu, Dec 5, 2013 at 8:38 PM, Jay Pipes <jaypi...@gmail.com> wrote: > On 12/04/2013 12:10 PM, Russell Bryant wrote: >> >> On 12/04/2013 11:16 AM, Nikola Đipanov wrote: >>> >>> Resurrecting this thread because of an interesting review that came up >>> yesterday [1]. >>> >>> It seems that our lack of a firm decision on what to do with the mocking >>> framework has left people confused. In hope to help - I'll give my view >>> of where things are now and what we should do going forward, and >>> hopefully we'll reach some consensus on this. >>> >>> Here's the breakdown: >>> >>> We should abandon mox: >>> * It has not had a release in over 3 years [2] and a patch upstream for 2 >>> * There are bugs that are impacting the project with it (see above) >>> * It will not be ported to python 3 >>> >>> Proposed path forward options: >>> 1) Port nova to mock now: >>> * Literally unmanageable - huge review overhead and regression risk >>> for not so much gain (maybe) [1] >>> >>> 2) Opportunistically port nova (write new tests using mock, when fixing >>> tests, move them to mock): >>> * Will take a really long time to move to mock, and is not really a >>> solution since we are stuck with mock for an undetermined period of time >>> - it's what we are doing now (kind of). >>> >>> 3) Same as 2) but move current codebase to mox3 >>> * Buys us py3k compat, and fresher code >>> * Mox3 and mox have diverged and we would need to backport mox fixes >>> onto the mox3 three and become de-facto active maintainers (as per Peter >>> Feiner's last email - that may not be so easy). >>> >>> I think we should follow path 3) if we can, but we need to: >>> >>> 1) Figure out what is the deal with mox3 and decide if owning it will >>> really be less trouble than porting nova. To be hones - I was unable to >>> even find the code repo for it, only [3]. If anyone has more info - >>> please weigh in. We'll also need volunteers >>> >>> 2) Make better testing guidelines when using mock, and maybe add some >>> testing helpers (like we do already have for mox) that will make porting >>> existing tests easier. mreidem already put this on this weeks nova >>> meeting agenda - so that might be a good place to discuss all the issues >>> mentioned here as well. >>> >>> We should really take a stronger stance on this soon IMHO, as this comes >>> up with literally every commit. >> >> >> I think option 3 makes the most sense here (pending anyone saying we >> should run away screaming from mox3 for some reason). It's actually >> what I had been assuming since this thread a while back. > > > What precisely is the benefit of moving the existing code to mox3 versus > moving the existing code to mock? Is mox3 so similar to mox that the > transition would be minimal? > > >> This means that we don't need to *require* that tests get converted if >> you're changing one. It just gets you bonus imaginary internet points. >> >> Requiring mock for new tests seems fine. We can grant exceptions in >> specific cases if necessary. In general, we should be using mock for >> new tests. > > > My vote would be to use mock for everything new (no brainer), keep old mox > stuff around and slowly port it to mock. I see little value in bringing in > another mox3 library, especially if we'd end up having to maintain it.
FWIW this is exactly what the Cinder team agreed upon a while back and the direction we've been going. There hasn't really been any push-back on this and in most cases the response from people has been "Wow, using mock was so much easier/straight forward". > > Best, > -jay > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev