midnight braindump

[William Reade]

On Tue, 2012-10-02 at 22:11 -0300, Gustavo Niemeyer wrote:
> 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.

+1

> > 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.

Hmm. I personally feel that the real point of HookContext is that it's
primarily a dumb struct that can be constructed by anyone; but, yeah,
making it an interface would fulfil the same uses in a nicer way.

> I have a proposal that bases itself on yours:
> 
> 1) Move cmd/jujuc/server to uniter/jujuc

OK.

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

Yeah, shouldn't be a major problem to do at any time. Although once it's
done I think I will be agitating for a rename of uniter/jujuc to
uniter/tools.

> 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

OK, I think that we can make clear progress by creating a jujuc.Context
and converting the commands to use the interface instead of the existing
concrete types. I think that doing this will make the next step much
clearer.

> 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.

I still think a hook.Env will end up very clean, but we'll see :). 

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

Yeah, my initial email is really just saying "there's something trying
to jump out but I can't yet see it clearly".

> (...)
> > 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.

I almost suggested the same myself, and they *are* the same from a
certain perspective, but I worry that such a type is in danger of
becoming rather unwieldy. There is *definitely* code to be saved by
consolidation, though, and I'll bear that in mind.

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

I think we should be able to come up with a better name than jujuc,
which was entirely born from the "be a nice binary name" constraint.

Anyway, I will add this to the list of things I'll try to do soonish.

Cheers
William

> 
> 
> gustavo @ http://niemeyer.net