Merge lp:~ev/uci-engine/nfss-fixes into lp:~canonical-ci-engineering/uci-engine/nfss
Status: | Merged |
---|---|
Merge reported by: | Thomi Richards |
Merged at revision: | not available |
Proposed branch: | lp:~ev/uci-engine/nfss-fixes |
Merge into: | lp:~canonical-ci-engineering/uci-engine/nfss |
Diff against target: |
26 lines (+3/-3) 1 file modified
juju-deployer/nf-data-collector.yaml.tmpl (+3/-3) |
To merge this branch: | bzr merge lp:~ev/uci-engine/nfss-fixes |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Thomi Richards | Pending | ||
Canonical CI Engineering | Pending | ||
Review via email: mp+224522@code.launchpad.net |
Description of the change
We pin dependencies and charms in lp:uci-engine so two deployments that only differ in time produce the same results. The motivation being that if the deployment breaks, you know it's because of code you changed. Adding the python3 version of the gunicorn charm broke this:
➜ nfss-fixes ./juju-
cannot import name compare_trees
lp:~canonical-ci-engineering/charms/trusty/gunicorn/gunicorn-py3-support is not pinned to a revno.
1
I also took the opportunity to install the python 2 version of pyramid again. It is co-installable with the python3 version. Supporting both means we don't have to keep a separate copy of the charm for services that haven't been transitioned to python3.
There's no need to install test dependencies with the production service, so I removed mock and webtest from the juju-deployer configuration.
why support python2 and python3 for pyramid if we are only doing python3? If/when we need python2-pyramid, i don't mind adding the logic but that just adds X more things to install now?