Support for "undefok"?

[josvisser66]

The Google flags library for C++ has an interesting feature called --undefok: https://gflags.github.io/gflags/. This works as follows:

./a.out --undefok=foo,bar --foo --bar=5

does not throw an error if the binary does not understand --foo and --bar. This is useful in cloud situations where the deployment of the binary and the deployment of the command line flags have different paths that are not necessarily synchronized. Imagine you added a new flag to the binary (--foo) and press the buttons to build and distribute the new binary. Then at the same time you want to go to the deployment descriptor and add "--undefok=foo --foo" so that the new binary is configured with --foo while at the same time making sure that the old binary that might get restarted somewhere does not barf on the presence of this flag (that it does not yet understand).

Afaics Clap does not yet understand something like this, nor is there another good way to implement this. I was thinking of adding this to Clap through an option that makes a Vec behave like --undefok. Thoughts?

[ldm0]

You can file a issue for this. I think it's a good feature.

[pksunkara]

I don't agree. In fact, I don't even understand half of what you wrote. You should probably explain it a bit more with good sample cli commands and what the output is, etc...

[josvisser66]

Imagine the following:

• You add a command line flag to a program: Say --foo.
• This program runs on thousands of computers in a private or public cloud.
• The program needs to be compiled and distributed to these thousands of computers.
• You have a system for that, which automatically (on a schedule) builds the binary and starts the rollout over the thousands of computers.
• For reasons of safety this process takes multiple days. For instance you first roll out in a test environment, let it bake there for a day, then start the rollout in the production environment, which takes multiple days because you go slowly and go region by region.
• The scripts that start the program in these test and production environments contain the command line for the program.
• You want to edit these scripts and add --foo.
• Unfortunately once you do that (and depending on the vagaries of the cloud system), the scripts could be used to (re)start older versions of the binary, which do not understand --foo yet, and therefore crash.
• This problem could be solved if we could tell the older binaries to ignore specific flags that they don't know about yet.
• This is what the proposed feature is.
• By modifying the startup scripts to specify --undefok=foo --foo we achieve the following things: Old binaries will ignore --foo and new binaries will honour --foo.
• Then at some point in the future, we don't care when, we can edit the scripts again and remove --undefok=foo, when we are certain that --foo is honoured everywhere.

This might seem like a really exotic scenario, but in bigger deployments this happens quite regularly.

[klepikov]

I can second that this is a very common need in large production deployments. Essentially it's needed any time we add a new required flag – where the flag might be technically optional, but the production deployment requires a particular non-default value when running the respective new code. In a system where production container configuration (which includes the flags) updates are not necessarily always 1:1 synchronized with the binary updates, there will always be scenarios where a newer binary would run with an older config and vice versa. Without a way to accept undefined flags, one would have to make changes in 3 stages:

1. Add just the flag definition, with no code that depends on it yet.
2. Deploy it to production, wait for it to rollout to absolute 100%, including containers that might have been down during the initial rollout, but might come back up later, e.g. due to a regional outage.
3. Deploy the code that depends on the flag.

This is obviously toily and error prone.

The --undefok functionality that @josvisser66 describes has been standard in gflags for a very long time, for this specific reason. It is part of standard production deployment practices, and its absence in Rust unfortunately creates another point of friction for wide Rust adoption on the backend – it's a matter of "production maturity" of the language libraries, in a way.

We can debate the pros and cons of independent vs. guaranteed-synchronized config & binary push – there definitely are pros and cons in each type, but either way we are not going to change existing deployment systems at multiple shops.

[dimo414]

I'll echo the support for something resembling --undefok. It's not the sort of thing you'd need in a CLI application, but it's very useful for deployed binaries like servers. #1404 seems somewhat related, though the motivation for that FR was different.

Also hi @klepikov :)

[wchargin]

You can file a issue for this.

You should probably explain it a bit more with good sample cli commands and what the output is, etc...

I’ve opened #2354 with some more explanation and sample CLI commands.