uniter: HookContext.Config is now consistent

uniter: HookContext.Config is now consistent

fixes lp:1063619

https://code.launchpad.net/~fwereade/juju-core/consistent-config-in-hook/+merge/128992

(do not edit description out of merge proposal)

[fwereade, 2012-10-10 16:26:40]

Please take a look.

[niemeyer, 2012-10-10 18:47:30]

LGTM, except for the drop of service from HookContext.

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go
File worker/uniter/context.go (left):

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go#oldcode41
worker/uniter/context.go:41: func NewHookContext(service *state.Service, unit
*state.Unit, id string, relationId int, remoteUnitName string, relations
map[int]*ContextRelation) *HookContext {
This is the case we were talking about when I suggested unit.Service() was a bad
idea. The caller of this function generally will hold the service already.
There's no reason for us to be forcing the logic within the context to be
reloading the service every time it needs to look at the service again. I
suggest preserving the service field as we had before, and using it as needed.

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go
File worker/uniter/context.go (right):

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go#newcode22
worker/uniter/context.go:22: // config holds the service's config.
// config holds the service configuration.

[fwereade, 2012-10-10 21:48:33]

*** Submitted:

uniter: HookContext.Config is now consistent

fixes lp:1063619

R=niemeyer
CC=
https://codereview.appspot.com/6642060

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go
File worker/uniter/context.go (left):

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go#oldcode41
worker/uniter/context.go:41: func NewHookContext(service *state.Service, unit
*state.Unit, id string, relationId int, remoteUnitName string, relations
map[int]*ContextRelation) *HookContext {
On 2012/10/10 18:47:30, niemeyer wrote:
> This is the case we were talking about when I suggested unit.Service() was a
bad
> idea. The caller of this function generally will hold the service already.
> There's no reason for us to be forcing the logic within the context to be
> reloading the service every time it needs to look at the service again. I
> suggest preserving the service field as we had before, and using it as needed.

Done.

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go
File worker/uniter/context.go (right):

https://codereview.appspot.com/6642060/diff/1/worker/uniter/context.go#newcode22
worker/uniter/context.go:22: // config holds the service's config.
On 2012/10/10 18:47:30, niemeyer wrote:
> // config holds the service configuration.

Done.