midnight braindump

[Gustavo Niemeyer]

On Tue, Oct 2, 2012 at 7:15 PM, William Reade
<william.reade at canonical.com> wrote:
> Hey all
>
> I was just poking at Uniter.runHook(), and pondering how it really
> *ought* to look, and I'm approaching a solution roughly like this (with
> many details elided):
>
> cmd/hook
>   type Context struct // once server.HookContext
>   func (*Context) NewCommand(string) (cmd.Command, error)
>   type RelationContext struct // interface? see later
>   // all hook tools: relation-set, config-get, etc
>
> cmd/jujuc/server
>   type Server struct
>   // etc, but only the servery bits

I have been secretly thinking about jujuc as well, but in a different
context. I'd like to kill the idea that we have a different command
for it, and incorporate the logic from the client-side commands into
jujud itself. This will halve the binary size of tools uploads and
downloads, with no bad side.

> worker/uniter/hook
>   type Env struct
>   func NewEnv(st *state.State, unitName, charmDir, toolsDir,
>     socketPath string) (*Env, error)
>   func (*Env) RunHook(Info, map[int]*hook.RelationContext)
>
> In this formulation, a hook.Env draws together everything a hook needs
> to execute. It runs a permanent jujuc server, which allows it to provide
> the implementation of the hook tools, and is also responsible for
> everything about the environment in which the hook process executes; it
> also logs it and interprets its errors and so on.

This sounds like a good idea, but it also feels like very similar
goals to those we've originally assigned to what we've put together as
server.HookContext. It'd be nice if we could have a single one of
those instead.

I have a proposal that bases itself on yours:

1) Move cmd/jujuc/server to uniter/jujuc

2) Integrate the runner of cmd/jujuc into cmd/jujud (postponable)

3) Drop RelationContext and HookContext from uniter/jujuc

4) Define jujuc.Context interface offering what commands need

5) Introduce concrete Context implementation in the uniter, or in uniter/hook

The details of (5) are not clear to me. Not sure if these types
require a new package or if they fit well within the uniter package
itself. The runHook method seems relatively simple so far, but it will
be enriched to integrate more of what is currently in
HookContext.RunHook and friends, so this may require refactoring it
into a Runner type or similar.

My suggestion here is not trying to design too much upfront. We can
evolve runHook until the design jumps out.

(...)
> I am feeling a strong pressure to move quite a lot of Relationer into
> Uniter (EnterScope/LeaveScope, and StateDir manipulation) and the rest
> into hook.Env (that is, everything RelationContext-manipulating --
> possibly including moving much of the implementation of RelationContext
> into Env too and turning hook.RelationContext into an interface with
> Settings() and WriteSettings() (is it really just that? it might be,
> near enough!)).

I think hook.Env, HookContext, and RelationContext are all the same thing.

My suggestion is unifying them behind an interface, jujuc.Context that
must be implemented by whatever wants to run a jujuc.Server.


gustavo @ http://niemeyer.net