<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 14, 2014 at 2:58 AM, Monty Taylor <span dir="ltr"><<a href="mailto:mordred@inaugust.com" target="_blank">mordred@inaugust.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 07/10/2014 02:44 PM, Richard Jones wrote:<br>
> On 10 July 2014 23:27, Mulcahy, Stephen <<a href="mailto:stephen.mulcahy@hp.com">stephen.mulcahy@hp.com</a>> wrote:<br>
>> When I last tested bandersnatch, it didn’t work well behind a proxy (in<br>
> fact most of the existing pypi mirroring tools suffered from the same<br>
> problem) – pypi-mirror has worked extremely well for mirroring a subset of<br>
> pypi and doing so behind a proxy. I’d also echo the requirement for a tool<br>
> that provides wheels as we have seen significant performance improvement<br>
> from using wheels with TripleO<br>
><br>
> devpi works behind a proxy. If bandersnatch doesn't then that bug should be<br>
> addressed ASAP. I'm in contact with its author regarding that.<br>
><br>
> I'm currently investigating a sensible approach to having wheels be<br>
> automatically built (for the most sensible value of "automatic" that we can<br>
> determine <wink>).<br>
<br>
</div></div>We're also thinking about how we continue to offer the pre-built wheels<br>
for each of our build platforms. For infra, what I'm thinking is:<br>
<br>
On each mirror slave (We have one for each OS combo we use), do<br>
something similar to:<br>
<br>
pip wheel -r global-requirements.txt<br>
rsync $wheelhouse <a href="http://pypi.openstack.org/$(lsb_release)" target="_blank">pypi.openstack.org/$(lsb_release)</a><br>
<br>
This may require keeping pypi-mirror and using an option to only do<br>
wheel building so that we can get the directory publication split. Ok. I<br>
got bored and wrote that:<br>
<br>
<a href="https://review.openstack.org/106638" target="_blank">https://review.openstack.org/106638</a><br>
<br>
So if we land that, you can do;<br>
<br>
pip wheel -r global-requirements.txt<br>
run-mirror --wheels-only --wheelhouse=wheelhouse --wheeldest=mirror<br>
rsync -avz mirror pypi.openstack.org:/srv/mirror<br>
<br>
If we went the devpi route, we could do;<br>
<br>
pip wheel -r global-requirements.txt<br>
for pkg in $wheelhouse; do<br>
  devpi upload $pkg<br>
done<br>
<br>
And put that into a cron.</blockquote><div><br></div><div>Obviously "keeping pypi-mirror" would require the least amount of change to how we suggest developers set up their systems.</div><div><br></div><div>I think the devpi option seems fairly reasonable too. It looks like it's easier (and faster, and less bandwidth-consuming) than setting up bandersnatch or apt-mirror, which we currently suggest people consider. It doesn't look any more heavyweight than having a squid proxy for caching, which we currently suggest as a bare minimum.</div>

<div><br></div><div>For an individual dev testing their own setup, I think we need a slightly different approach from the infra approach listed above though. I'm assuming that it's possible to probe the package index to determine if a wheel is available for a particular version of a package yet. If that's the case, we should be able to tweak tools like os-svc-install to notice when no wheel is available, and build and upload the wheel.</div>

<div><br></div><div>I think this should give us a good balance between making sure that each build (except the first) uses wheels to save time, still gets the latest packages (since the last time the system was online at least), and the user doesn't need to remember to manually update the wheels when they're online.</div>

</div></div></div>