Status

Current state: Under Discussion

Discussion thread: – (discussion prior to FLIP)

JIRA: –

Released: –

Please keep the discussion on the mailing list rather than commenting on the wiki (wiki discussions get unwieldy fast).

Motivation

Flink currently requires configuration to be written to file. By allowing to override this configuration through environment variables, configuration can be made much more flexible. This becomes particularly useful in Kubernetes scenarios where some of the configuration can be defined through secrets exposed as environment variables, e.g. access keys. Furthermore, Flink can benefit from this internally as well as this mechanism provides an easy way to randomize end-to-end test configuration, see FLINK-19520.

The specific approach proposed here is inspired by, and follows in large parts, the design of the equivalent feature of the Spring framework. This provides confidence as the feature has been excessively used already, and familiarity with developers who have a knowledge overlap.

Public Interfaces

No public interfaces apart from configuration are affected. Flink configuration is also not affected directly, but indirectly by virtue of allowing environment variable to override entries in the Flink configuration.

Proposed Changes

After the Flink configuration has been parsed from the file, environment variables (following a clearly defined naming schema, see below) are taken into consideration and are allowed to amend or even replace the parsed configuration. Allowing environment variables to take precedence over the configured values is a deliberate and important choice.

Compatibility, Deprecation, and Migration Plan

• What impact (if any) will there be on existing users? 
• If we are changing behavior how will we phase out the older behavior? 
• If we need special migration tools, describe them here.
• When will we remove the existing behavior?

Test Plan

Describe in few sentences how the FLIP will be tested. We are mostly interested in system tests (since unit-tests are specific to implementation details). How will we know that the implementation works as expected? How will we know nothing broke?

Rejected Alternatives

If there are alternative ways of accomplishing the same thing, what were they? The purpose of this section is to motivate why the design is the way it is and not some other way.