<div dir="ltr">I agree with Flavio. This looks really cool, and I had a very similar idea recently. I'll try to find some time to give this a whirl.<div><br></div><div>-Dave</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 5, 2014 at 10:37 AM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@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="HOEnZb"><div class="h5">On 09/05/2014 04:21 PM, Monty Taylor wrote:<br>
> On 09/05/2014 06:32 AM, Sean Dague wrote:<br>
>> While reviewing this zookeeper service group fix in Nova -<br>
>> <a href="https://review.openstack.org/#/c/102639/" target="_blank">https://review.openstack.org/#/c/102639/</a> it was exposed that the<br>
>> zookeeper tests aren't running in infra.<br>
>><br>
>> The crux of the issue is that zookeeper python modules are C extensions.<br>
>> So you have to either install from packages (which we don't do in unit<br>
>> tests) or install from pip, which means forcing zookeeper dev packages<br>
>> locally. Realistically this is the same issue we end up with for mysql<br>
>> and pg, but given their wider usage we just forced that pain on<br>
>> developers.<br>
>><br>
>> But it seems like a bad stand off between testing upstream and testing<br>
>> normal path locally.<br>
>><br>
>> Big picture it would be nice to not require a ton of dev libraries<br>
>> locally for optional components, but still test them upstream. So that<br>
>> in the base case I'm not running zookeeper locally, but if it fails<br>
>> upstream because I broke something in zookeeper, it's easy enough to<br>
>> spin up that dev env that has it.<br>
>><br>
>> Which feels like we need some decoupling on our requirements vs. tox<br>
>> targets to get there. CC to Monty and Clark as our super awesome tox<br>
>> hackers to help figure out if there is a path forward here that makes<br>
>> sense.<br>
><br>
> Funny story - I've come to dislike what we're doing here, so I've been<br>
> slowly working on an idea in this area:<br>
><br>
> <a href="https://github.com/emonty/dox" target="_blank">https://github.com/emonty/dox</a><br>
><br>
> The tl;dr is "it's like tox, except it uses docker instead of<br>
> virtualenv" - which means we can express all of our requirements, not<br>
> just pip ones.<br>
><br>
> It's not quite ready yet - although I'd be happy to move it in to<br>
> stackforge or even openstack-dev and get other people hacking on it with<br>
> me until it is. The main problem that needs solving, I think, is how to<br>
> sanely express multiple target environments (like py26,py27) without<br>
> making a stupidly baroque config file. OTOH, tox's insistence of making<br>
> a new virtualenv for each "environment" is heavyweight and has led to<br>
> some pretty crazy hacks across the project. Luckily, docker itself does<br>
> an EXCELLENT job at handling caching and reuse - so I think we can have<br>
> a set of containers that something in infra (waves hands) publishes to<br>
> dockerhub, like:<br>
><br>
>   infra/py27<br>
>   infra/py26<br>
><br>
> And then have things like nova build on those, like:<br>
><br>
>   infra/nova/py27<br>
><br>
> Which would have zookeeper as well<br>
><br>
> The _really_ fun part, again, if we can figure out how to express it in<br>
> config without reimplementing make accidentally, is that we could start<br>
> to have things like:<br>
><br>
>   infra/mysql<br>
>   infra/postgres<br>
>   infra/mongodb<br>
><br>
> And have dox files say things like:<br>
><br>
>   Nova unittests want a python27 environment, this means we want an<br>
> infra/mysql container, an infra/postgres container and for those to be<br>
> linked to the infra/nova/py27 container where the tests will run.<br>
><br>
> Since those are all reusable, the speed should be _Excellent_ and we<br>
> should be able to more easily get more things runnable locally without<br>
> full devstack.<br>
><br>
> Thoughts? Anybody wanna hack on it with me? I think it could wind up<br>
> being a pretty useful tool for folks outside of OpenStack too if we get<br>
> it right.<br>
><br>
<br>
</div></div>I think it is sexy - I don't describe ideas/software as sexy that often<br>
but this one deserves it. I'm interested in helping out.<br>
<br>
I'll clone it and give it a try - or at least take a look at it.<br>
<br>
Flavio<br>
<span class="im HOEnZb"><br>
> Monty<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>
<br>
<br>
</span><span class="HOEnZb"><font color="#888888">--<br>
@flaper87<br>
Flavio Percoco<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><br><br clear="all"><div><br></div>-- <br><div dir="ltr"><div>David Shrewsbury (Shrews)<br></div></div>
</div>