No need for parenthesis.

This seems like it would override the value for any test that want to set it explicitly.

dito

I'm not sure we want to cache command line arguments. Or if so, then there needs to be some cache invalidation logic. Thinking about this more, it seems like this is the proper approach: add a facility to add elements to the config file used by the node.

I think Amaury is pointing out that by altering the args after creating the node, setting -greatwallactivationtime overrides values that are set explicitly in tests. This is probably not the intent, as the test should pass in the state it was set at.

However, I see a problem with this approach no matter how you slice it:

1. A non-overriding implementation will only catch tests that will fail on flagday, but not tests that need to be updated to cover new behavior.
2. An overriding implementation like this one will break tests that are intended only to operated under the activation time explicitly specified in the tests.

Given the above, I think #1 is the right way to go, as tests that need to be updated can be easily grep'd for. Our main concern is what breaks on flagday.

1. Prepending self.extra_args is likely to fail, because the self.extra_args that are set at init can be overridden at each node start() or restart(), giving many opportunities for the test to clear the flag (override in these cases is achieved by assignation, not appending)
2. The actual TestNode implementation is weird regarding arguments. I don't think that adding a new attribute such as the suggested self.override_args is the best solution, it is another layer of arguments which is confusing.

So far the best approach imo is to refactor the TestNode to add accessors for self.args, maybe renaming it to clarify its intent. This would make the changes no longer rely on TestNode internal behavior.
Any thought ?