I was looking into bug #1297094, which is about a race between bootstrap
and actually being ready for Deploy to work.
The particular bug is that we bootstrap, start the jujud process, and
return. And then while the API server is coming up, it can take longer to
bring up the HTTP Storage (localstorage) worker than for us to respond to
an AddCharm request.
Which means that AddCharm wants to put the data into local storage, but
local storage isn't responding yet.
it brought to mind that we have a general pattern for Worker that we know
when they are started (because we create them), and we can stop them
(Kill), and we can know when they are done (Wait). However, we don't have a
way for them to tell us that they are actually all set up and ready to
operate.
I was thinking we might want to add an (optional?) interface to Worker that
was:
func Running() <-chan struct{}
And then when Workers have gotten to the point that they consider
themselves ready to respond to requests, they can just close their
'running' channel.
The RunnerWorker can then just proxy for all Workers that it is starting
(it doesn't signal running until all workers it starts are dead or running).
A different option is that we call this "Started()" but have it not trigger
when we think we are instantiating the object, but instead when that object
considers itself ready. I don't care as much about the name as I care about
the idea that calling runner.StartWorker() is completely racy vs that
worker actually being ready to respond.
Is there a better pattern for this?
John
=:->
--
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
