<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 4, 2013 at 11:16 AM, Nikola Đipanov <span dir="ltr"><<a href="mailto:ndipanov@redhat.com" target="_blank">ndipanov@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/19/2013 05:52 PM, Peter Feiner wrote:<br>
> On Tue, Nov 19, 2013 at 11:19 AM, Chuck Short <<a href="mailto:chuck.short@canonical.com">chuck.short@canonical.com</a>> wrote:<br>
>> Hi<br>
>><br>
>><br>
>> On Tue, Nov 19, 2013 at 10:43 AM, Peter Feiner <<a href="mailto:peter@gridcentric.ca">peter@gridcentric.ca</a>> wrote:<br>
>>><br>
>>> A substantive reason for switching from mox to mock is the derelict<br>
>>> state of mox releases. There hasn't been a release of mox in three<br>
>>> years: the latest, mox-0.5.3, was released in 2010 [1, 2]. Moreover,<br>
>>> in the past 3 years, substantial bugs have been fixed in upstream mox.<br>
>>> For example, with the year-old fix to<br>
>>> <a href="https://code.google.com/p/pymox/issues/detail?id=16" target="_blank">https://code.google.com/p/pymox/issues/detail?id=16</a>, a very nasty bug<br>
>>> in nova would have been caught by an existing test [3].<br>
>>><br>
>>> Alternatively, a copy of the upstream mox code could be added in-tree.<br>
>>><br>
>> Please no, I think we are in an agreement with mox3 and mock.<br>
><br>
> That's cool. As long as the mox* is phased out, the false-positive<br>
> test results will be fixed.<br>
><br>
> Of course, there's _another_ alternative, which is to retrofit mox3<br>
> with the upstream mox fixes (e.g., the bug I cited above exists in<br>
> mox3). However, the delta between mox3 and upstream mox is pretty huge<br>
> (I just checked), so effort is probably better spent switching to<br>
> mock. To that end, I plan on changing the tests I cited above.<br>
><br>
<br>
</div>Resurrecting this thread because of an interesting review that came up<br>
yesterday [1].<br>
<br>
It seems that our lack of a firm decision on what to do with the mocking<br>
framework has left people confused. In hope to help - I'll give my view<br>
of where things are now and what we should do going forward, and<br>
hopefully we'll reach some consensus on this.<br>
<br>
Here's the breakdown:<br>
<br>
We should abandon mox:<br>
* It has not had a release in over 3 years [2] and a patch upstream for 2<br>
* There are bugs that are impacting the project with it (see above)<br>
* It will not be ported to python 3<br>
<br>
Proposed path forward options:<br>
1) Port nova to mock now:<br>
  * Literally unmanageable - huge review overhead and regression risk<br>
for not so much gain (maybe) [1]<br>
<br>
2) Opportunistically port nova (write new tests using mock, when fixing<br>
tests, move them to mock):<br>
 * Will take a really long time to move to mock, and is not really a<br>
solution since we are stuck with mock for an undetermined period of time<br>
- it's what we are doing now (kind of).<br>
<br>
3) Same as 2) but move current codebase to mox3<br>
 * Buys us py3k compat, and fresher code<br>
 * Mox3 and mox have diverged and we would need to backport mox fixes<br>
onto the mox3 three and become de-facto active maintainers (as per Peter<br>
Feiner's last email - that may not be so easy).<br>
<br></blockquote><div><br></div><div>So I thought we cleared this up already. We convert the current codebase over to mox3, new tests should be done in mock. Eventually we start converting over code to use mock.<br></div>
<div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we should follow path 3) if we can, but we need to:<br>
<br>
1) Figure out what is the deal with mox3 and decide if owning it will<br>
really be less trouble than porting nova. To be hones - I was unable to<br>
even find the code repo for it, only [3]. If anyone has more info -<br>
please weigh in. We'll also need volunteers<br>
<br></blockquote><div><br></div><div>Monty and I did this last cycle, its apart of the openstack project, although its not available in gerrit. Which should be fixed so we can start getting bug fixes in for it.<br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) Make better testing guidelines when using mock, and maybe add some<br>
testing helpers (like we do already have for mox) that will make porting<br>
existing tests easier. mreidem already put this on this weeks nova<br>
meeting agenda - so that might be a good place to discuss all the issues<br>
mentioned here as well.<br>
<br>
We should really take a stronger stance on this soon IMHO, as this comes<br>
up with literally every commit.<br></blockquote><div><br></div><div>totally<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Nikola<br>
<br>
[1] <a href="https://review.openstack.org/#/c/59694/" target="_blank">https://review.openstack.org/#/c/59694/</a><br>
[2] <a href="https://pypi.python.org/pypi/mox" target="_blank">https://pypi.python.org/pypi/mox</a><br>
[3] <a href="https://pypi.python.org/pypi/mox3/0.7.0" target="_blank">https://pypi.python.org/pypi/mox3/0.7.0</a><br>
<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>
><br>
<br>
<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><br></div></div>