status eod 18-jan-2013 (roughly)

[William Reade]

Hey all

I will be spottily available next week (if at all) but will try to keep
my own work ticking over and keep participating in reviews when I can. I
currently have the following branches out for review:

https://codereview.appspot.com/7138062/ destroy-service, almost trivial

https://codereview.appspot.com/7142043/ destruction API cleanup (may
involve argument re Right Thing, but the actual change is mechanical).

I'm halfway through fixing lp:1072750, lp:1101144, and lp:1033852, all
of which are aspects of imperfect relation addition; they may or may not
get finished next week and/or split out into separate CLs, but they're
all somewhat interconnected and I'd appreciate a heads-up if anyone else
needs to hit the state code related to relation lifecycles and/or
consistency.

I also kinda started a sketch of juju destroy-machine (lp:1073976) but
haven't assigned it to myself because I can't guarantee I'll do it in
the next few days: mainly because we need a little design discussion, as
follows:

When we're destroying a list of entities [0], there are a whole bunch of
states they could be in, and it's not quite clear how we should respond
to the various subsets of the following states among the list:

* invalid name (error)
* doesn't exist (error)
* entity Alive (error immediately if not eligible (eg subordinate unit,
  or machine with principals)(?)... or maybe just Destroy() and see what
  error we get)
* entity Dying (skip, no error)
* entity Dead (??? -- should we distinguish between dead and noexist?) 

It seems *potentially* nicest to attempt to destroy every supplied
entity regardless of failure in other entities, but it's not clear how
best to communicate status back to the user. Logging errors as they
occur would seem sane, except logs are swallowed by default in the CLI;
packing all problems into a single error return may be nicer, but might
end up producing unreadable output unless we break the single-line-error
convention. [1]

At the moment, though, we bail on the first error and don't do anything
at all unless all the supplied units are Alive and eligible for
destruction; I'm pretty certain this is behaviour could be improved.

Does anyone have any opinions on the above?

Cheers
William


[0] just units/machines for now; whether we *should* be able to remove
multiple services in one command is a separate discussion, but for now I
don't because python doesn't.

[1] I kinda think we might want to break that convention for ambiguous
endpoint errors too. Anyone agree? Perhaps cmd could handle:

type VerboseError interface {
    error
    VerboseError() string
}

...and we could implement those where needed? (MultilineError()?)