mirrord v3 UX

[aviramha]

Hey.
We're getting close to v3 release and part of the release is changing the UX.
Version 3 is expected to have the following features:

1. Remote traffic (TCP) duplication
2. Remote traffic (TCP) steal
3. Local outgoing traffic tunneling - TCP + UDP (?)
4. Environment variables loading
5. DNS Resolution

Now, the default use case for exec would be in my that all features are enabled by default, and you can toggle each off starting from overall "off toggle" to specific.

mirrord exec --pod-name very-nice-pod1 node app.js

would duplicate traffic, tunnel local outgoing traffic, load environments and use remote dns resolution.

mirrord exec --pod-name very-nice-pod1 --steal node app.js

would steal traffic, tunnel local outgoing traffic, load environments and use remote dns resolution.
Also, as part of this I suggest to have .mirrord file that we'll look for configuration, so you could just do

mirrord exec --pod-name very-nice-pod1

and the service would run with all relevant other flags and command line.
You will also be able to choose file by specifying -f or --profile-file or by name of profile (in case a profile file a list of different profiles).

This is WIP, feel free to step in.

[DmitryDodzin]

Should the default use case be set under duplication?

It might change how the code handles persistent services that are accessed (if the copy-on-write feature isn't implemented for that protocol), a sort of race condition where features like indexes/constraints/etc... can return different results to the local machine opposed to the remote process.

Id expect by default the traffic be stolen unless the developer knows for a fact the other relevant services in the cluster can handle duplicated messages and return the same result for both instances.

[eyalb181]

I don't think there's a clear-cut answer here - both mirroring and stealing can be potentially harmful to the environment if used irresponsibly. I'm leaning slightly towards mirroring as the default because that's what I would expect from a tool called mirrord :)

[DmitryDodzin]

About .mirrord file it might be simpler for the end user to mount all the args via clap's env feature and load .env file from the directory where the cli is executed at, it'll keep it consistent with the cli and also docs available via --help without extra work.

Unless there will be a need to add some functionality that is simply will be too bulky or just not easy to pass to the cli, for example overriding dns resolutions like a hosts file

[aviramha]

About .mirrord file it might be simpler for the end user to mount all the args via clap's env feature and load .env file from the directory where the cli is executed at, it'll keep it consistent with the cli and also docs available via --help without extra work.

Unless there will be a need to add some functionality that is simply will be too bulky or just not easy to pass to the cli, for example overriding dns resolutions like a hosts file

It's a possible solution, but I imagine that you'd have various "run" profiles for a service depending on what you want to test. Also usually the .env file would be used by your service and not by us (but we can load it for the user ofc)

[aviramha]

P.S see suggestions here on UX #395