Activity log for bug #1032539

Date Who What changed Old value New value Message
2012-08-03 08:37:55 William Reade bug added bug
2012-08-03 08:38:14 William Reade juju-core: assignee Frank Mueller (themue)
2012-08-03 08:40:12 William Reade juju-core: milestone 1.2
2012-08-03 08:40:20 William Reade juju-core: importance Undecided Critical
2012-08-03 10:00:38 William Reade description The first client that desperately needs lifecycles to work is the unit agent, which needs to track relation lifecycle. I hope I'm not going to regret this, but I *think* that all I need is a ServiceRelationsWatcher that produces these: type RelationsChange struct { Changed []*Relation } The initial event should contain every relation, whatever its state; subsequent ones should contain only the relations whose state has changed since the last event. I have come to the conclusion that I actually don't need separate Alive/Dying/Dead fields in the event. (Relation needs Life and SetLife, or whatever it was we agreed on.) The first client that desperately needs lifecycles to work is the unit agent, which needs to track relation lifecycle. I hope I'm not going to regret this, but I *think* that all I need is a ServiceRelationsWatcher that watches a specific service's relations throughout their lifecycle and produces these: type RelationsChange struct {     Changed []*Relation } The initial event should contain every relation, whatever its state; subsequent ones should contain only the relations whose state has changed since the last event. I have come to the conclusion that I actually don't need separate Alive/Dying/Dead fields in the event. AIUI, it will need to: * watch the topology for changes to the service's relations as it currently does * on relevant topology change: * for each added relation: * store its life status, and start a life watch *unless* it is already dead * report all added relations in a single event * on life change (that was started on new topology relation) * if life status is Dead, stop the relation's life watch * report the single changed relation in a single event In my mind, this kinda assumes a LifeWatcher type that guarantees it won't send the same status more than once, but guarantees it *will* send a Dead event if the node is deleted before it notices a change to Dead. (Relation needs Life and SetLife, or whatever it was we agreed on.)
2012-08-09 10:42:39 Frank Mueller juju-core: status New In Progress
2012-08-20 15:00:02 Frank Mueller juju-core: milestone 1.2 2.0
2012-08-20 15:00:04 Frank Mueller branch linked lp:~themue/juju-core/go-state-service-relation-watcher
2012-08-20 15:04:40 Frank Mueller juju-core: milestone 2.0 1.3
2012-08-31 11:22:59 Mark Ramm juju-core: milestone 1.3 1.4
2012-09-28 15:20:35 Frank Mueller juju-core: importance Critical High
2012-10-19 06:15:59 William Reade juju-core: status In Progress Fix Released