Remove pip_get_pip_options override from group_vars
In the group_vars pip_get_pip_options is set with the intention
of restricting the initial pip install to using the local repo
server first, then reaching out to a set upstream repo.
The pip install role then has a fallback which ignores these
settings and goes to pypi to fetch the versions required.
While this works, it causes an initial failure to install pip
when the repo server is not yet available. This is OK considering
that there isa fallback, but when other pip install options
need to be used (eg: proxy options, certificate validation
disabling due to bad proxies) then circumstances are reached
where both tasks will fail and pip is uninstallable.
Going back to the original intent, the use of this setting in
group_vars is a logic flaw. If there's a repo server already,
then everywhere where it matters the pip_lock_down role would
have already restricted pip install options to make use of the
local repo server for the first task in pip_install anyway. In
other words we're double-doing the lock down unnecessarily.
This patch results in the following behaviour:
- The first pip install task will look for the versions specified
in the local repo if there is one and the pip_lock_down task has
run on the host in question.
- If there is no local pip.conf, the first pip install task will
seek the packages from pypi.
- If the deployer chooses to set 'pip_get_pip_options' in
user_variables, then those options will be honoured.
Reviewed: https:/ /review. openstack. org/296594 /git.openstack. org/cgit/ openstack/ openstack- ansible/ commit/ ?id=3cdac57fc81 7e8e7bfed7a5fec b38baa66fe9e86
Committed: https:/
Submitter: Jenkins
Branch: master
commit 3cdac57fc817e8e 7bfed7a5fecb38b aa66fe9e86
Author: Jesse Pretorius <email address hidden>
Date: Wed Mar 23 16:29:29 2016 +0000
Remove pip_get_pip_options override from group_vars
In the group_vars pip_get_pip_options is set with the intention
of restricting the initial pip install to using the local repo
server first, then reaching out to a set upstream repo.
The pip install role then has a fallback which ignores these
settings and goes to pypi to fetch the versions required.
While this works, it causes an initial failure to install pip
when the repo server is not yet available. This is OK considering
that there isa fallback, but when other pip install options
need to be used (eg: proxy options, certificate validation
disabling due to bad proxies) then circumstances are reached
where both tasks will fail and pip is uninstallable.
Going back to the original intent, the use of this setting in
group_vars is a logic flaw. If there's a repo server already,
then everywhere where it matters the pip_lock_down role would
have already restricted pip install options to make use of the
local repo server for the first task in pip_install anyway. In
other words we're double-doing the lock down unnecessarily.
This patch results in the following behaviour:
- The first pip install task will look for the versions specified pip_options' in variables, then those options will be honoured.
in the local repo if there is one and the pip_lock_down task has
run on the host in question.
- If there is no local pip.conf, the first pip install task will
seek the packages from pypi.
- If the deployer chooses to set 'pip_get_
user_
This patch paves the way for https:/ /review. openstack. org/296114
to actually be something useful to have merged.
Closes-Bug: 1559619 711b969eddee0c4 52e2ba16664
Change-Id: I148e3628a75d81