Today ate-setup takes its install settings from three places:
.ate-dev-env.sh at the root of the checkout it runs from- the shell environment
ate-setup flags in cmd/ate-setup/commands.md.
That makes any redeploy risky, and an upgrade redeploys every component. For example: deploy atenet without --atenet-dataplane, --experimental-use-sdsmint, --experimental-egress-credential-injection .etc goes back to the default dataplane and drops the egress features.
Proposal
Scope: OSS only.
Add a config file for ate-setup, passed with --config.
It holds all the settings that define the install shape, such as image repos, image tags (for release), the atenet dataplane and egress features, telemetry and the database. An user (substrate operator) keeps one file and passes it to every run, including upgrades.
.ate-dev-env.sh may stay for developers.
Open questions
- One file with a section per component, or one file per component? ate-api-server is getting its own proto-based config file by Taahir Ahmed (@ahmedtd) , maybe the installer config could embed that type instead of repeating its fields.
- Precedence between the config file, the environment and flags, which overwrite which?
Today
ate-setuptakes its install settings from three places:.ate-dev-env.shat the root of the checkout it runs fromate-setupflags incmd/ate-setup/commands.md.That makes any redeploy risky, and an upgrade redeploys every component. For example:
deploy atenetwithout--atenet-dataplane,--experimental-use-sdsmint,--experimental-egress-credential-injection.etc goes back to the default dataplane and drops the egress features.Proposal
Scope: OSS only.
Add a config file for
ate-setup, passed with--config.It holds all the settings that define the install shape, such as image repos, image tags (for release), the atenet dataplane and egress features, telemetry and the database. An user (substrate operator) keeps one file and passes it to every run, including upgrades.
.ate-dev-env.shmay stay for developers.Open questions