pypi / salt Goto Github PK

Right now pypi.python.org and testpypi.python.org use host names to decide what to serve. These should each be on their own port (with TLS) and should be served regardless of the host name.

There are a number of redirects that redirect several of the "alternate" names for pypi.python.org (a.pypi.python.org etc). These will be handled by front.python.org for the time being but will ultimately be removed on Feb 15, 2014 anyways.

Sometime in Mid March (After PyCon) we'd like to deploy Warehouse for real, before that it would be nice to have Warehouse setup for deployment. This can either be a temporary quick deployment or a we can put more effort into it up front and get it "right" to start with.

Some wants/needs:

• Deploy from Warehouse master branch in a CD fashion to a "staging" instance.
• Promote Deploys from staging to a "production" instance.
• Be able to rollback deploys to earlier deployments with the assumption that there has been a total catastrophic failure in PyPI and we cannot rely on the PyPI being up.
  • It can be reasonable to expect that the mirror itself is up though.
• Deploy using the latest PyPy (and ideally track this closeish).

Off the top of my head I think that RPM is probably the most reasonable way to handle this deployment. Inside the RPM we could either do a bundled virtualenv or go the omnibus route.

One thing we do need to think about is how to handle the staging/production distinction. An RPM by default is going to have the same path and can't be installed more than once. This could mean that we need to make "staging" and "production" RPMs although it would be nice to use the same bits for staging/production. Other options are using separate VMs for production/staging or trying to use Docker.

c.f. https://bitbucket.org/pypa/pypi/issue/85/oauth-authorise-not-found-https-must-be

There's no reason to have port 80 -> 443 redirects. Fastly will always connect to these backend servers over TLS, and Fastly itself handles the HTTP -> HTTPS redirect.

Pythonhosted needs setup (Without TLS) on some port and exposed so that front.python.org can connect to it.

When running vagrant up, the following error message is printed:

Error: Cannot retrieve metalink for repository: epel. Please verify its path and try again
 * ERROR: Failed to run install_centos_git_deps()!!!

According to this, the error is caused by CentOS 6.3 EPEL repos defaulting to SSL 3.0, and includes the fix of running:

sudo sed -i "s/mirrorlist=https/mirrorlist=http/" /etc/yum.repos.d/epel.repo

in the VM to fix it.

Ideally, this change should be made automatically when provisioning.

Can we do this? Is it already being done? It would be really great if we could!

RPMs built for Python 2.7.6 and m2crypto will be signed and hosted some place proper.