Jeremy, Thanks for the clarification.
I found an alternative workaround that works for me and restricts the use of the openstack pypi mirror to only be used when running tox: 1. Add PyPi mirror to tox.ini's [tox] entry: +indexserver = + default = http://pypi.openstack.org/openstack e.g. [tox] minversion = 1.6 skipsdist = True envlist = py26,py27,py33,pep8 indexserver = default = http://pypi.openstack.org/openstack Ramy Reference: http://stackoverflow.com/questions/16471269/how-to-tell-tox-to-use-pypi-mirrors-for-installing-packages -----Original Message----- From: Jeremy Stanley [mailto:fu...@yuggoth.org] Sent: Thursday, February 13, 2014 6:44 PM To: openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] Devstack installation failed with CINDER installation On 2014-02-13 10:56:28 -0600 (-0600), Ben Nemec wrote: [...] > configure pip to use the pypi.openstack.org mirror. [...] While this is sometimes a useful hack for working around intermittent PyPI CDN growing pains on your personal development workstation, or maybe for ferreting out whether your local tests are getting different results because of varied package set between PyPI and our mirror, I fear that some people reading this might assume it's a stable public service and encode it into production configuration. The pypi.openstack.org mirror is just a single VM, while pypi.python.org has CDN services fronting it for improved reachability, reliability and scalability. In fact, pypi.openstack.org resides on the same single-point-of-failure VM which also provides access to build logs and lots of other data. It's intended mostly as a place for our automated build systems to look for packages so as not to hammer actual PyPI constantly and to provide us an additional layer of control over what we test with. It is *not* secure. Let me reiterate that point. It is for test jobs, so the content is served via plain unencrypted HTTP *only* and is therefore easily modified by a man-in-the-middle attack. It's also not guaranteed to be around indefinitely, or to necessarily be reachable outside the cloud provider networks where testing is performed, or to carry all the packages you may need, or to have enough bandwidth available to serve the entire user base, or to be up and on line 100% of the time, or... ...you get the idea. -- Jeremy Stanley _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
