Lint

docs/DESIGN.md

@@ -38,7 +38,7 @@ up/downscaling, no multiple versions routed by header.
 Specifically: no downscaling to zero. It makes everything MUCH
 more complicated.
 
-# Function structure
+## Function structure
 
 Example using crystal, but it could be anything. Any function has
 an associated runtime, for example "crystal" or "python".
@@ -69,7 +69,9 @@ Probably some `metadata.yml` that is *not* in the template.
 * Files that should be copied along the function
 * Whatever
 
-# Implementation Ideas
+## Implementation Ideas
 
 * caddy for proxy? It's simple, fast, API-configurable.
-* Local docker registry for images? See https://www.docker.com/blog/how-to-use-your-own-registry-2/ (maybe later)
+* Local docker registry for images? See
+  [use own registry](https://www.docker.com/blog/how-to-use-your-own-registry-2/)
+  (maybe later)

docs/deployments.md

@@ -15,34 +15,31 @@ Solution: start the funko on the server. Done. It's implemented.
 
 ## Variant 3: Deploy to the server and it's already running
 
-1. If it's already running and it's running the latest image, then nothing to be done.
-2. It it's running and is not the latest, we can stop it and start with the latest image.
+1. If it's already running and it's running the latest image, then nothing
+   to be done.
+2. It it's running and is not the latest, we can stop it and start with the
+   latest image.
 
 * Action 2 causes downtime. Usually it will not be significant, but it's there.
 * In the future it may be important to have zero downtime.
 * We need to figure out what is implied by doing "zero downtime" to see if
   not doing it now would make it impossible.
 
-For zero downtime, we want to have two instances running, switch the proxy to the new
-one, then stop the old one.
+For zero downtime, we want to have two instances running, switch the proxy
+to the new one, then stop the old one.
 
 Currently it's impossible to run two instances because the container name is
 faaso-funkoname, and we can't have 2 of those.
 
-So: we could instead have faaso-funkoname-1, faaso-funkoname-2, etc. with some sort of suffix
+So: we could instead have faaso-funkoname-1, faaso-funkoname-2, etc.
+with some sort of suffix
 
 Changes implied in the faaso code:
 
-* If we have two containers for one funko, we need to consider the "state" of 
+* If we have two containers for one funko, we need to consider the "state" of
   the funko differently.
 * What does it mean to start/pause/stop a funko with two instances
 * Do we want to enable two-instance funkos? With round-robin proxy?
 * What happens if we have two instances with different images?
 
 Answers coming up.
-
-
-
-
-
-

docs/funkos.md

@@ -49,10 +49,12 @@ faaso-net.
 The proxy is the only container exposed to the host network, everything
 else needs to be accessed through it.
 
-The faaso-proxy container will automatically proxy all requests so if you access the URL `http://faaso-proxy:8888/funko/hello/foo` that will be
+The faaso-proxy container will automatically proxy all requests so if
+you access the URL `http://faaso-proxy:8888/funko/hello/foo` that will be
 proxied to `/foo` in the `hello` funko.
 
-This is all done via naming conventions. You can create your own `faaso-whatever` container, add it to the `faaso-net` and faaso will
+This is all done via naming conventions. You can create your own
+`faaso-whatever` container, add it to the `faaso-net` and faaso will
 happily consider it a funko.
 
 In the same way all funkos are simply docker containers running in that
@@ -78,4 +80,3 @@ faaso-proxy -- GET /bar --> faaso-funko1
 The dynamic proxying is achieved by reading the current state of
 Docker and just adapt to it using the naming conventions mentioned
 above.
-

docs/secrets.md

@@ -31,7 +31,7 @@ So, the proxy can periodically examine its secret store and populate a folder
 If on starting a funko we always do a bind mount of `/secrets/foo` to `/secrets`
 then it will always have its secrets in place.
 
-## Problem 2: how can the proxy know the secrets without keeping them in the image?
+## Problem 2: how can the proxy know the secrets without keeping them in the image
 
 They can't be shipped via the image, so they need to be injected via the admin API.