Using multiple machines for the same application

[radu-matei]

Both draft connect and draft logs try to get the latest build ID locally, from the logs directory. This makes both commands much faster, but also makes the assumption that the same machine was used to draft up and to get the logs / connect.

If there were two machines used, on the second machine the user doesn't have any way of doing draft logs (since the logs are only stored locally), nor draft connect, since it requires the latest build ID.

For draft logs there is no clear way of solving this unless we store the logs in the cluster as well.

For draft connect:

• we can try to get the build ID locally, and if there is none we get it from the history (which is stored on the cluster) - the problem here is that if the build on the cluster is newer than the one locally (there was a draft up from another machine), you cannot connect
• we can always get the build ID from the cluster - which will increase the connection time.

The question: is the scenario above often enough so that it justifies the increase in the connection time?

[radu-matei]

For example I just switched between Windows, WSL and macOS with the same cluster, but I don't think that's a sane thing that people do very often.

[bacongobbler]

semi-related discussion around this concern: https://github.com/Azure/draft/issues/585

[squillace]

@gabrtv I know you were interested in this area.

[radu-matei]

Do we have any more thoughts here?

One scenario that happens with the current setup: since all logs are written in $DRAFT_HOME/logs and are not grouped by the application name, if you're working with on the same machine with app A and app B: you execute:

app B: $ draft up

app A: $ draft logs - here you see the build logs from app B

We can:

• group the logs by application name
• get the latest build ID from the cluster

Thoughts?

[bacongobbler]

I think we've made some good moves in regards to draft logs via enhancements like #664, so that part has been accomplished if I'm reading this right. I think at this point the last thing we need to tackle is to fetch the latest build ID from the storage backend as mentioned in the original comment, right?

[radu-matei]

The workflow could be:

• draft logs fetches the latest build ID from the storage backend
• it searches for logs in the local directory - if present, fetch those
• if not, get them from the storage backend

Since our storage is based on config maps (whose size limit is I think 1 MB) - how would we handle log files larger than 1 MB?