Merge lp://qastaging/~doanac/uci-engine/restish-code-layout into lp://qastaging/uci-engine
Status: | Superseded |
---|---|
Proposed branch: | lp://qastaging/~doanac/uci-engine/restish-code-layout |
Merge into: | lp://qastaging/uci-engine |
Diff against target: |
434 lines (+140/-80) 8 files modified
charms/precise/restish/charm-helpers.yaml (+1/-0) charms/precise/restish/config.yaml (+0/-10) charms/precise/restish/hooks/hooks.py (+64/-52) charms/precise/restish/unit_tests/test_hooks.py (+67/-13) ci-utils/ci_utils/unit_config.py (+6/-1) juju-deployer/gatekeeper.yaml.tmpl (+0/-2) juju-deployer/nf-stats-service.yaml.tmpl (+0/-2) nf-stats-service/nfss/database.py (+2/-0) |
To merge this branch: | bzr merge lp://qastaging/~doanac/uci-engine/restish-code-layout |
Related bugs: |
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
Canonical CI Engineering | Pending | ||
Review via email:
|
Commit message
restish charm: reorganize code layout and improve install logic
This does a couple of things that were hard to do piece by piece. The
change is a bit big but:
The main goal was getting our code to be in its own directory so it
can start to be treated like read-only. We have an idea in the future
of code rollbacks, so this fits in with that model. This now deploys
code to:
/srv/<
and we maintain a symlink to the latest code with:
/srv/<
While doing this I got rid of all the bzr-branch logic we no longer
use. This reduces complexity.
I'll also converted our tarball logic to use charmhelpers.fetch.
While changing so much, I also decided to improve our code-extraction
logic by moving it to our config-changed logic. This means that
we now have the ability to update code by just changing the payload
value of the service.
I am fine losing the ability to deploy branches, but others might disagree and ask why a similar re-organisation cannot be done checking branches. I think the VCS support brings more troubles (access permission and slowness) then benefits, but it's worth checking someone's opinion on this.
There are few diff comments for your consideration and I am perfectly happy to approve the branch after they are addressed.
IFAICT, we are missing rewriting gunicorn.conf and restarting the service to have `juju set <unit> payload_ url=<new_ tarball_ in_swift> ` and voilá, unit will be running new code, correct ?