Merge lp:~paulgear/charms/trusty/grafana/layer-grafana-reactive-states-fix into lp:~canonical-is-sa/charms/trusty/grafana/layer-grafana
Proposed by
Paul Gear
on 2016-07-20
| Status: | Merged |
|---|---|
| Approved by: | Nick Moffitt on 2016-07-20 |
| Approved revision: | 48 |
| Merged at revision: | 41 |
| Proposed branch: | lp:~paulgear/charms/trusty/grafana/layer-grafana-reactive-states-fix |
| Merge into: | lp:~canonical-is-sa/charms/trusty/grafana/layer-grafana |
| Diff against target: |
228 lines (+74/-33) 3 files modified
README.md (+2/-2) layer.yaml (+1/-0) reactive/grafana.py (+71/-31) |
| To merge this branch: | bzr merge lp:~paulgear/charms/trusty/grafana/layer-grafana-reactive-states-fix |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Stuart Bishop | Approve on 2016-07-21 | ||
| Nick Moffitt | 2016-07-20 | Approve on 2016-07-20 | |
|
Review via email:
|
|||
To post a comment you must log in.
lp:~paulgear/charms/trusty/grafana/layer-grafana-reactive-states-fix
updated
on 2016-07-20
- 43. By Paul Gear on 2016-07-20
-
Latest stable
- 44. By Paul Gear on 2016-07-20
-
Add repo to keep charm build happy
- 45. By Paul Gear on 2016-07-20
-
Revert repo change; contra https:/
/packagecloud. io/grafana/ stable/ install# manual, trusty does not exist - 46. By Paul Gear on 2016-07-20
-
Add upgrade charm hook
- 47. By Paul Gear on 2016-07-20
-
Prevent race in calling add_backup_
api_keys( ) - 48. By Paul Gear on 2016-07-20
-
Clarify reason for commented-out state
lp:~paulgear/charms/trusty/grafana/layer-grafana-reactive-states-fix
updated
on 2016-07-21
review:
Approve

I've been thinking out loud a lot about this merge while in the office, and it boils down to basically one thing that's sorely needed when using the reactive model:
Locking semantics.
The (now deprecated, I hope) only_once decorator is the most obvious example of this. Unfortunately the implementation doesn't fit our needs, but the desire it expresses is a good one. What you've gone through and done for a lot of this is to add "When not Y" to a lot of "When X" conditions. Again, this ensures that the non-idempotent steps are only run once.
I have always fought for idempotent state-enforcing changes, but accept that those aren't always possible. I'm not sure what the Right Thing is, but this change is definitely not Wrong!