Calling relation-set multiple times, clears previous values
Bug #719699 reported by
Kapil Thangavelu
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
pyjuju |
Fix Released
|
Critical
|
Kapil Thangavelu |
Bug Description
<SpamapS> Interesting.. one thing that was somewhat unexpected.. in one hook, I called 'relation-set' twice w/ different vars..
<SpamapS> like.. relation-set ip=X;relation-set port=Y
<SpamapS> this resulted in no ip
<SpamapS> which now, I understand...
<SpamapS> but at the time, it was somewhat confusing.
<kapil> hmm.. that sounds odd
<kapil> SpamapS, that should work
<kapil> all the changes made by a hook are buffered till the hook completes and then flushed atomically to zookeeper
* kapil checks
<kapil> SpamapS, that's definitely a bug
Related branches
lp:~hazmat/pyjuju/hook-multi-set
- Gustavo Niemeyer: Approve
-
Diff: 70 lines (+13/-4)4 files modifiedensemble/agents/tests/test_unit.py (+5/-3)
ensemble/hooks/protocol.py (+2/-1)
ensemble/hooks/tests/test_communications.py (+3/-0)
ensemble/state/hook.py (+3/-0)
Changed in ensemble: | |
importance: | Undecided → Critical |
milestone: | none → capetown |
status: | New → In Progress |
assignee: | nobody → Kapil Thangavelu (hazmat) |
Changed in ensemble: | |
status: | In Progress → Fix Released |
To post a comment you must log in.
31<kapil> bcsaller, i think i found the issuse .. so the hook api is calling set with a dictionary, which effectively replaces the dict, instead of calling through to set value, which merges with the existing state. bcsaller >21 kapil: agreed
31<kapil> in terms of how the hook context is managing state
18<bcsaller> huh
31<kapil> the set with dictionary api was there to support full scale replacement of values, ie. to support things like deleting values as well
31<kapil> bcsaller, i'm not sure how you would distinguish on the hook api server though
31<kapil> whether a client called with multiple values on a single line. vs stdin value replacement
31<kapil> bcsaller, yeah.. the distinction is a bit too subtle, there should probably be a more explicit delete exposed via a magic value on the client side hook api
21<