Hmm... long thread.<br><br>Anyway: I&#39;m +1 on using a CDN.  I think the overhead of managing a mirror network is considerably greater than the cost of the CDN, and more error-prone.  With a CDN one developer can figure out how to implement this in PyPI, and any problems will be with PyPI, not some other mirror system that the person debugging the problem doesn&#39;t control.<br>

<br>I think your cost only covers bandwidth, but there are also storage costs.  What disk space are the PyPI packages using right now?  That will only increase over time as PyPI generally keeps all releases.  Possibly CDN space could be donated.  As an implementation note, Google&#39;s new system copies S3&#39;s API (<a href="http://code.google.com/apis/storage/">http://code.google.com/apis/storage/</a>) -- I&#39;m not sure if it covers the same territory as CloudFront though.  Anyway, implementing to S3/CloudFront probably is a good bet even if the provider changes in the future.<br>

<br>For generation /simple/ with a cronjob, I&#39;m -0.  I find these delays make testing difficult and unreliable; you can never be sure if the job is just slow, what you did didn&#39;t work, etc.  I&#39;d rather see PyPI shift to creating static pages on-demand, that is, anytime they need updating.  Then if PyPI goes down the static pages still exist and work, but there&#39;s no delay.  Another option might be a caching proxy configured to serve up cached copies when the underlying system is down... but I&#39;m not sure if that&#39;s any less work ultimately, and is more ongoing administration.<br>

<br>I don&#39;t see a benefit to moving further into the cloud, such as hosting on multiple machines.  I suspect that PyPI is not anywhere near needing more power than a good sized server can provide, and I doubt that will change soon.  It will be easier to manage the system with a single machine and database.  There won&#39;t be network problems where app servers can&#39;t access the database, for instance.  Or a need for replication, which is another big potential administration hassle.<br>

<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
 * scalability<br>
 * 24/7 system administration management<br>
 * geo-localized fast and reliable access<br>
<br>
<br>
Current Situation<br>
-----------------<br>
<br>
PyPI is currently run from a single server hosted in The Netherlands<br>
(<a href="http://ximinez.python.org" target="_blank">ximinez.python.org</a>).  This server is run by a very small team of sys<br>
admin.<br></blockquote><div><br>As far as I know, none of this changes how much administration load there is, does it?  That is, cloud machines still need to be administered.  The only way I see that you&#39;d really decrease administration load is with a more radical move to a managed service, like App Engine.  That&#39;s probably quite doable and would have substantial advantages, but it feels like a quite different approach than is proposed here and it involves lots more coding.<br>

<br>Unless there really is a problem with the physical management of the server?<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


Server side: upload cronjobs<br>
----------------------------<br>
<br>
Since the /simple index tree is currently being created dynamically,<br>
we&#39;d need to create static copies of it at regular intervals in order<br>
to upload the content to the S3 bucket. This can easily be done using<br>
tools such as wget or curl.<br>
<br>
Both the static copy of the /simple tree and the static files uploaded<br>
to /packages then need to be uploaded or updated in the S3 bucket by a<br>
cronjob running every 10-20 minutes.<br></blockquote><div><br>Is it easy to sync something with S3?  It&#39;s easy to upload, delete, etc., but sync is rather different, no?  Not a big deal, just that changes would have to be tracked if sync was not efficient. <br>

</div><div> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Server side: redirection setup<br>
------------------------------<br>
<br>
Since PyPI wasn&#39;t designed to be put on a CDN, it mixes static file<br>
URL paths with dynamic access ones, e.g.<br>
<br>
dynamic:<br>
<br>
 <a href="http://pypi.python.org/pypi" target="_blank">http://pypi.python.org/pypi</a><br>
 (and a few others)<br>
<br>
static:<br>
<br>
 <a href="http://pypi.python.org/simple" target="_blank">http://pypi.python.org/simple</a><br>
 <a href="http://pypi.python.org/packages" target="_blank">http://pypi.python.org/packages</a><br>
<br>
To move part of the URL path tree to a CDN, which works based on<br>
domains, we will need to provide a URL redirection setup that<br>
redirects client side tools to the new location.<br></blockquote><div><br>As far as I know /packages isn&#39;t accessed directly, but only from links from /simple -- so if those links are updated everything should work.  Some packages already aren&#39;t on PyPI, so there&#39;s no particular expectation about hosting location.<br>

<br>If /simple/ is a set of static files hosted on ximinez, will it be reliable enough?  Then no redirects will be required.  I don&#39;t know what exactly has caused failures.  If it&#39;s networking then redirects would help.  If it&#39;s services failing, then static files will solve it.  If it&#39;s the entire machine getting wonky, e.g., if memory is exhausted... then quite possible static files will help avoid those situations but it&#39;s not a guarantee.<br>

</div></div><br>-- <br>Ian Bicking  |  <a href="http://blog.ianbicking.org">http://blog.ianbicking.org</a><br>