It is understandable that commands targetting remote pods and hosts involve opening and closing connections. However, the Connection to <IP> closed. message at the end is potentially confusing. Example:

sns pod logs mypod

Output:

1617604253 simplenetes_io 10.0.2.100 - - [05/Apr/2021:06:30:53 +0000] "GET / HTTP/1.1" 206 364 "-" "Mozilla/5.0" "10.0.2.100"
1617604342 simplenetes_io 10.0.2.100 - - [05/Apr/2021:06:32:22 +0000] "GET / HTTP/1.1" 200 364 "-" "abc/1.1" "10.0.2.100"
1617604514 simplenetes_io 10.0.2.100 - - [05/Apr/2021:06:35:14 +0000] "GET / HTTP/1.1" 200 364 "-" "dfg" "10.0.2.100"
1617616950 simplenetes_io 10.0.2.100 - - [05/Apr/2021:10:02:30 +0000] "HEAD / HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.67 Safari/537.36" "10.0.2.100"
Connection to <redacted IP> closed.

• Is k8s conformance on the project's roadmap?
  • if so, what's the timeline?
• If not, what are the limitations besides the lack of namespaces and auto-scaling?

I wasn't able to find the answer in the docs, hence the question

host.env KEYFILE has a relative path while host-superuser.env has an absolute path.

This becomes an error when pulling the cluster-repo to another location on disk.

Right now sns supports two release methods for pods: hard (default) and soft.

The hard release is focused on a quick release process from the Ops perspective. It will stop the old pod version and run the new version in the same transaction, which likely gives a small glitch in uptime.

The soft process takes longer time as as it has both versions running with overlap before retiring the old version.

We would want a safe method which guarantees that there is no overlap between version. Which is desirable when
running processes which should never concurrently access the same file. For example a database.

Sometimes just seeing the actual traffic can unclog issues.

Using tcpdump instead of messing with pods is a very non-intrustive way of doing this.

We need tools for listing volumes, opening a shell into volumes, downloading volumes, purging old volumes.

The standalone executable currently located in the release directory could be offered as part of every new version release here: https://github.com/simplenetes-io/simplenetes/releases

This would allow one to more easily download the latest version from the command line using "latest" as version instead of having to specify a particular version.

Relative directory references were originally intended to serve the reuse of pods between clusters. However, referencing directories alone, missing or not, should not trigger the creation of new directories (mkdir).

Note:

we should consider movingexisting pods to be inside the cluster repository instead

Potential downside:

... one has to clone all the pods once for each cluster

Related data:

• /pod directories: local podDir="$(FILE_REALPATH "${PODPATH}/${pod}")"
• Cluster path: PODPATH: ${PODPATH:-\$CLUSTERPATH/../pods}
• mkdir -p calls

Example in parent directory relative to CLUSTERPATH:

/media/mysite$ sns cluster ps
mkdir: cannot create directory ‘/media/mysite/../pods’: Permission denied
mkdir: cannot create directory ‘/media/pods’: Permission denied

To have secrets encrypted as safe as possible we would a specific service which serves up decrypted secrets to the ramdisks of pods.

I'm think s/--quite/--quiet/ was the intention with Spacefile.sh#L441 and its associated consumers?

The ordering of versions of pods is not ordered.

Consider adding colored output if stdout is a terminal according to [ -t 1 ].

To get a quick overview of the current status of a cluster one would like to run:

sns cluster ps

Right now, the function does nothing.

It would be nice to be able to stream logs from pods

Given the following command:

sns CONTEXT

Current output:

[ERROR] Unknown <CONTEXT> command ''

Suggested output:

Usage:
help
-h
    Output this help

version
-V
    Output the version of Simplenetes

sns CONTEXT COMMAND [OBJECT] [OPTIONS] [ARGUMENTS]

Cluster commands:
  cluster create <cluster name>
[...]

Host commands:
  host register <host>
[...]


Pod commands:
  pod ls [[pod[:version]][@host]]
[...]

Or just that particular help usage. Example:

sns host

Targetted output:

sns host COMMAND [OBJECT] [OPTIONS] [ARGUMENTS]

Host commands:
  host register <host>
[...]

Could also consider applying the same to invalid commands, but that is more understandable as it is (in comparison to the case of empty commands).
Invalid command:

sns CONTEXT invalid

Current output:

[ERROR] Unknown <CONTEXT> command 'invalid'