v0.3

Writable fs

This release expends the fs so it is no longer read-only. Now you can:

• Delete objects by deleting the .yaml files
• Duplicate objects by copying .yaml files into new ones
• Create new objects from scratch by copying files into the right place in the file system

Warning

⚠️ The file system is now writable, and can change or delete things in your kubernetes cluster. Be careful not to run any tools that might, for example rm -rf your entire cluster. ⚠️

Some notes

When writing a file, the apiVersion, kind, name and namespace are completely ignored and replaced by whatever is appropriate to that file's location and name. This means if I write a file into <context>/deployment/ns/my-deployment.yaml, I will always get the following header:

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: ns
  name: my-deployment

The end result is that copying yaml (or json) files around will create new objects rather than overwriting the old ones - because we changed the filename.

Things to try

• Duplicate a deployment

  cp $context/deployments/default/app.yaml $context/deployments/default/app-copy.yaml

• Create a new secret - since these don't have default values, we don't actually need to include anything in the file to create an empty object

  echo > $context/secrets/default/my-secret
  # Now edit it in our favorite IDE
  code $context/secrets/default/my-secret
  nano $context/secrets/default/my-secret
  vi $context/secrets/default/my-secret

What we're working on next

See our roadmap for some missing functionality - for example:

• you can't create new files with vs code, because it tries to read the file and errors out
• file system watchers aren't implemented yet, so IDEs can't show updated object values
• some quirks still exist in how missing fs functionality is worked around
• we'd like to add comments to the yaml when applying them fails, showing hints on how to fix them