* Laurent Bercot <ska-skaware_at_skarnet.org> [20150424 00:24]:
> On 23/04/2015 23:26, Joan Picanyol i Puig wrote:
> >I'd really expect a ui that can "diff" "compiled" & "live" vs. "source"
> >(and
> >obviously, to inspect "compile" & "live").
>
> There will definitely be a ui to inspect compiled + live.
>
> As for diffing the current state vs. source, I think it will be too
> complex, because it would amount more or less to performing the work
> of the compiler again. What can be done is something that compares
> two "compiled" databases, so to diff against the source, you would
> compile the source into a temp database then compare the temp to the
> current compiled.
That would certainly be enough.
> >I find ./down so convinient that would like having support for it in the
> >"source" format.
>
> The thing is, s6-rc already makes use of ./down internally. When you
> run "s6-rc -d this-longrun-service", it first brings down everything
> that depends on this-longrun-service, then creates ./down in
> this-longrun-service's service directory in live, then calls
> s6-svc -d on this-longrun-service. It says that the service is supposed
> to be down and remain that way, because that is the state you want to
> see enforced.
I probably did not explain myself.
What I'd like is the ability to have some services "ready-to-run", but not
up by default. Some of them might be there for contingency purposes (so
that an operator can start a failover), some of them might have to go up
(and down) at certain times only.
If a longrun-service can't be source-annotated with ./down, this use
case requires configuring a oneshot-service just to 's6-rc -d' it which
looks akward to say the least.
> > > I am thinking about a utility, "s6-rc-update", that would take the
> > > live, the old compiled and the new compiled as inputs, and that
> > > would update the live as smartly as possible, with carefully
> > > designed heuristics; users could also tell s6-rc-update exactly
> > > what to do via annotations in the source, that s6-rc-compile would
> > > translate into the new compiled.
> > >
> >Any heuristics will face unsolvable situations. I'd aim at getting the
> >"patch" (dual of "diff" above) action right all the time first.
> >
> That can be done, but with or without heuristics, there will still need
> to be a tool to actually update the live state. "diff" is easier than
> "patch"; the details of "patch" are what I'm interested in.
I lack knowledge & experience to attempt to provide details, so I'll
just handwave poiting that the first concept to have clear is that of
"identity": is this servicedir a "new" service definition or a
modification of an existing one? It then should be feasible to compute
the modifications needed to the live DAG (inserting/removing nodes as
well as restarting them).
qvb
--
pica
Received on Sat Apr 25 2015 - 09:24:22 UTC