Remove now-done items from TODO
This commit is contained in:
parent
ea20a79885
commit
223b865e4f
49
TODO.md
49
TODO.md
|
@ -1,55 +1,6 @@
|
||||||
- signals (SIGTERM)
|
- signals (SIGTERM)
|
||||||
|
|
||||||
- service-started, service-running, and service-complete
|
|
||||||
- actually more like: stopped, starting, started, running, failed, and stopping.
|
|
||||||
- ... but with `complete` added, to mirror `failed`.
|
|
||||||
- service controls: reload?, restart, pause, unpause, force-stop ("blocked")
|
|
||||||
- difference between "pause" and "block" is that "pause" stops the
|
|
||||||
actual program instance but doesn't flag the service as
|
|
||||||
non-started, while "block" pushes it all the way back to
|
|
||||||
"stopped".
|
|
||||||
|
|
||||||
- deal with logging
|
- deal with logging
|
||||||
- when syslogd is running, /dev/log is a unix datagram socket
|
- when syslogd is running, /dev/log is a unix datagram socket
|
||||||
|
|
||||||
- service for `apk` operations - otherwise they clash
|
- service for `apk` operations - otherwise they clash
|
||||||
|
|
||||||
Service lifecycle (as freely imagined; really, a state machine similar
|
|
||||||
to this will be induced by assertion-driven
|
|
||||||
subconversations/facets...):
|
|
||||||
|
|
||||||
digraph G {
|
|
||||||
compound=true;
|
|
||||||
|
|
||||||
subgraph cluster_runnable {
|
|
||||||
label="Runnable";
|
|
||||||
running [label="running\n(a.k.a. ready)"];
|
|
||||||
starting -> started [label="deps satisfied\nstart svc"];
|
|
||||||
started -> running [label="marked running\n-"];
|
|
||||||
started -> failed [label="start failed\n-"];
|
|
||||||
started -> complete [label="svc done\n-"];
|
|
||||||
running -> failed [label="svc failed\n-"];
|
|
||||||
running -> complete [label="svc done\n-"];
|
|
||||||
failed -> started [label="restart\nstart svc"];
|
|
||||||
complete -> started [label="restart\nstart svc"];
|
|
||||||
running -> started [label="restart\nstart svc"];
|
|
||||||
}
|
|
||||||
stopped;
|
|
||||||
paused [label="running\n(paused)"];
|
|
||||||
blocked [label="stopped\n(blocked)"];
|
|
||||||
|
|
||||||
stopped -> starting [label="required\nscan deps"];
|
|
||||||
running -> stopped [label="unrequired\nstop svc"];
|
|
||||||
|
|
||||||
running -> paused [lhead=cluster_runnable, label="pause req\nstop svc"];
|
|
||||||
paused -> starting [label="unpause req\nscan deps"];
|
|
||||||
|
|
||||||
running -> blocked [lhead=cluster_runnable, label="block req\nstop svc"];
|
|
||||||
blocked -> stopped [label="unblock req\ncheck for requirement"];
|
|
||||||
|
|
||||||
paused -> blocked [label="block req\n-"];
|
|
||||||
}
|
|
||||||
|
|
||||||
Oh, how about having a set-of-states approach: one for the
|
|
||||||
supervision/dependency-resolution process, and one for the service
|
|
||||||
itself?
|
|
||||||
|
|
Loading…
Reference in New Issue