Code review comment for lp://staging/~hazmat/pyjuju/unit-stop
Revision history for this message
| William Reade (fwereade) wrote | # |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
5c6b958
demo site
(Get the code!)
couple of typos and some vague rambling thoughts; I'll try to write them
up in some more detail for the list.
https:/
File source/
https:/
source/
This example can be extended to
s/its/it's/
https:/
source/
[See Topology Internals]
Please define "relevant entities". When stopping a service, for example,
do you mean we should mark all the following:
- all units of that service
- all unit relations of that service
- all machines running only that service
- the service itself
?
I think it'd be easier to think of things cascading a bit more -- so
individual entities detected their own impending death by watching for
changes to their immediate parents' statuses... but I may have to think
it through a little more.
https:/
source/
file
Not sure about this; can't we just always write agents with a "normal
exit 0" stanza and depend on that?
Otherwise, if we get a "weird" failure at this precise point, we won't
get an opportunity to start up again and tidy ourselves up nicely; and
besides it seems more correct to me to let the machine agent *always*
tidy up the unit agent upstart files it originally created (which it
will have to do anyway if it times out...).
https:/
source/
s/exists/exits with a code indicating to upstart that it should not be
restarted/
(?)
https:/
source/
'stop' node deletion, shutsdown the units container.
s/shutsdown/shuts down/
But regardless, I think we need to consider this in a little more detail
-- we're not guaranteed to have a container, after all, and we probably
shouldn't be killing whole containers if we're just shutting down a
subordinate charm, for example.
https:/
source/
this.
If the PA kills a machine, it will then be responsible for cleaning up
the MA's nodes *and* any unit nodes? This doesn't seem quite right...
sounds like a job for the GC really (because -- I *think* -- it's going
to have to deal with unit cleanup as a consequence of forcible machine
termination. (If the MA doesn't handle a stop request properly, probably
it didn't stop its units either.).
https:/
source/
footprint and zk state.
I think this needs a bit more detail; see below.
https:/
source/
Sounds sensible. I'm wondering if it would be sensible to extend the
general idea to unit relations, replacing the existing mechanism; in
combination with a gc node, for example, it could be useful for units to
hold a don't-delete-yet lock on other participants in their relations
(until the point at which the unit itself has processed their removal).
(I think we do need something like this: a relation hook can
theoretically execute with an arbitrarily old members list, and the only
reason this isn't currently a problem is because we don't delete the old
members' settings nodes, so the relation hook commands can continue to
cheerfully extract data from dead unit relations. (I think, anyway: the
details have grown hazy. Please correct me if I need it ;)))
But then... if a UA holding a "lock" on another unit relation's settings
gets forcibly killed, we need a way to detect that *that* lock is no
longer relevant... it's not insoluble, sure, but it could get fiddly,
and whatever we do I think we'll need a semi-smart GC that can figure
out these sorts of issues, and I think it's worth speccing out the
details of the GC in a bit more depth.
https:/