From 9b7144047c5dabd4172b6c9f8a9a694bf1274e36 Mon Sep 17 00:00:00 2001 From: Reid 'arrdem' McKenzie Date: Tue, 7 Sep 2021 02:21:34 -0600 Subject: [PATCH] [NO TESTS] WIP --- projects/archlinux/rollback.py | 94 +++++++++++++++++++++++++++ projects/flowmetal/call_cc_airflow.md | 47 ++++++++++++++ 2 files changed, 141 insertions(+) create mode 100644 projects/archlinux/rollback.py create mode 100644 projects/flowmetal/call_cc_airflow.md diff --git a/projects/archlinux/rollback.py b/projects/archlinux/rollback.py new file mode 100644 index 0000000..f4e758d --- /dev/null +++ b/projects/archlinux/rollback.py @@ -0,0 +1,94 @@ +import os +import re +import sys + + +def main(opts, args): + """Usage: python rollback.py date + + Parse /var/log/pacman.log, enumerating package transactions since the + specified date and building a plan for restoring the state of your system to + what it was at the specified date. + + Assumes: + - /var/log/pacman.log has not been truncated + + - /var/cache/pacman/pkg has not been flushed and still contains all required + packages + + - The above paths are Arch default and have not been customized + + - That it is not necessary to remove any "installed" packages + + Note: no attempt is made to inspect the dependency graph of packages to be + downgraded to detect when a package is already transitively listed for + downgrading. This can create some annoying errors where eg. systemd will be + downgraded, meaning libsystemd will also be downgraded, but pacman considers + explicitly listing the downgrade of libsystemd when it will already be + transitively downgraded an error. + + """ + + date, = args + + print("Attempting to roll back package state to that of {0}...\n" + .format(date), + file=sys.stderr) + + # These patterns can't be collapsed because we want to select different + # version identifying strings depending on which case we're in. Not ideal, + # but it works. + + # Ex. [2017-04-01 09:51] [ALPM] upgraded filesystem (2016.12-2 -> 2017.03-2) + upgraded_pattern = re.compile( + ".*? upgraded (?P\w+) \((?P[^ ]+) -> (?P[^\)]+)\)") + + # Ex: [2018-02-23 21:18] [ALPM] downgraded emacs (25.3-3 -> 25.3-2) + downgraded_pattern = re.compile( + ".*? downgraded (?P\w+) \((?P[^ ]+) -> (?P[^\)]+)\)") + + # Ex: [2017-03-31 07:05] [ALPM] removed gdm (3.22.3-1) + removed_pattern = re.compile( + ".*? removed (?P\w+) \((?P[^ ]+)\)") + + checkpoint = {} + flag = False + + with open("/var/log/pacman.log") as logfile: + for line in logfile: + if date in line: + flag = True + elif not flag: + continue + + match = re.match(upgraded_pattern, line)\ + or re.match(downgraded_pattern, line)\ + or re.match(removed_pattern, line) + + if match: + package = match.group("name") + from_rev = match.group("from") + if package not in checkpoint: + checkpoint[package] = from_rev + continue + + print("Checkpoint state:") + for k in checkpoint.keys(): + print("{0} -> {1}".format(k, checkpoint[k]), file=sys.stderr) + + pkgcache = "/var/cache/pacman/pkg" + pkgs = os.listdir(pkgcache) + pkgnames = ["{0}-{1}".format(k, v) for k, v in checkpoint.items()] + + selected_pkgs = set([os.path.join(pkgcache, p) + for n in pkgnames + for p in pkgs + if n in p]) + + print("Suggested incantation:\n", file=sys.stderr) + print("sudo pacman --noconfirm -U {}" + .format("\\\n ".join(selected_pkgs))) + + +if __name__ == "__main__": + main(None, sys.argv[1:]) diff --git a/projects/flowmetal/call_cc_airflow.md b/projects/flowmetal/call_cc_airflow.md new file mode 100644 index 0000000..8b5bc3f --- /dev/null +++ b/projects/flowmetal/call_cc_airflow.md @@ -0,0 +1,47 @@ +# An Asynchronous, Distributed Task Engine + +This document presents a design without reference implementation for a distributed programming system; +sometimes called a workflow engine. +It is intended to provide architectural level clarity allowing for the development of alternative designs or implementations as may suit. + +## Problem Statement + +In building, operating and maintaining distributed systems (many computers in concert) engineers face a tooling gap. + +Within the confines of a single computer, we have shells (`bash`, `csh`, `zsh`, `oil` etc.) +and a suite of small programs which mesh together well enough for the completion of small tasks with ad-hoc automation. +This is an enormous tooling win, as it allows small tasks to be automated at least for a time with a minimum of effort and with tools close to hand. + +In interacting with networks, communicating between computers is difficult with traditional tools and communication failure becomes an ever-present concern. +Traditional automation tools such as shells are inadequate for this environment because achieving network communication is excessively difficult. + +In a distributed environment it cannot be assumed that a single machine can remain available to execute automation; +This requires an approach to automation which allows for the incremental execution of single tasks at a time with provisions for relocation and recovery should failure occur. + +It also cannot be assumed that a single machine is sufficiently available to receive and process incoming events such as callbacks. +A distributed system is needed to wrangle distributed systems. + +## Design Considerations + +- Timeouts are everywhere +- Sub-Turing/boundable +- + +## Architectural Overview + +### Events +Things that will happen, or time out. + +### Actions +Things the workflow will do, or time out. + +### Bindings +Data the workflow either was given or computed. + +### Conditionals +Decisions the workflow may make. + +### Functions +A convenient way to talk about fragments of control flow graph. + +### Tracing & Reporting