* Laurent Bercot <[email protected]> [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
