Client-Server Split RFC #141
Conversation
Signed-off-by: Magic_RB <[email protected]>
|
Every time we do so, it improves bit by bit, learning from past mistakes but starting with a clean slate. |
|
As for whether it's actually a good idea? I don't know. When I started writing deploy, the vision I had was of a really simple and dumb script that just does one thing. It turns out even the simplest profile deployment can get complicated once you add all the rollback logic. Maybe rewriting it and splitting it up is the right step. Maybe we should take a step in the other direction and get rid of some extra features (magic-rollback, other fancy activation stuff) in the name of simplicity and reliability of the tool itself, so that there's no need for a separate |
in which case having a referenceable specification would be a good thing! I also kindof wanted to do a lot of rewriting already, I've been pondering some issues and limitations of magic-rollback and came to the conclusion that most of that logic has to be redesigned from scratch, and could probably convert a lot of my thoughts to a similar RFC too |
|
|
||
| I propose to split `deploy-rs` into a server and a client, `deploy` and `activate` respectively. Basically, while now | ||
| `activate` is just a helper, this RFC proposes to make it a self standing program. The basic jist is that the two | ||
| components would communicate over a open ssh connection, using plain REST (this is important later). That would allow us |
There was a problem hiding this comment.
We'd have to make a new ssh connection to confirm activation anyways, since that's precisely what we're confirming (the ability to ssh into the machine).
Also, we'd need to reimplement nix copy for this. Should not be too difficult, but something to keep in mind.
There was a problem hiding this comment.
Well we'd still be down to 2 ssh connections from 3 or 4 or however many we have now
|
Rollback stuff makes it complicates yes, but at least after our current iteration of the codebase we know how it makes it complicated, so if we include it again we are aware how to implement it more cleanly without creating annoying logic problems and disrupting the readability of the rest of the code |
If I had to describe how I'd imagine a perfect future for this RFC and deploy-rs/yeet generally is that before writing a single line of code, we go though all the code we have now, write down all the features we have and then analyze what each feature encompasses, the requirements and such. Create api specifications. Then as the last step we just write code which compiles and works on the first attempt :D. |
How would that work? Because we need a smarter program on the remote machine to do cooler things, so I can't really imagine a way where we build something complex on a simpler base than we have now. Maybe plugins on both ends? The way I imagined it is that when you run yeet in single-client-mode, it installs the server component and then after its done removes itself from the target automatically, the complex nature would be completely hidden from the user in that case. |
|
should I expand on the proposal? I'd start with a detailed functionality description and feature set. |
Signed-off-by: Magic_RB [email protected]
You can find the text of this RFC here.