Repository navigation
Need an install settings from a config file to persist configurations #1887
Description
Today ate-setup takes its install settings from three places:
.ate-dev-env.shat the root of the checkout it runs from- the shell environment
ate-setupflags incmd/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 be removed reduce duplicate.
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?
Activity
HavenXia commentedon Sep 25, 2026
cc Grant McCloskey (@MushuEE) Benjamin Elder (@BenTheElder)
stshrive commentedon Sep 28, 2026
IMO, your second open question should be resolved in this order:
ENV < CONFIG < FLAGSIf someone goes through the trouble of setting a flag, it seems like that is the thing that is wanted. ENV variables bleed through things. So if someone has a Config, it should also take precedence over env.
HavenXia commentedon Sep 28, 2026
I agree on
ENV < CONFIG < FLAGS. An intentionally set config should overrides ENV, while flags is the highest.The thing that worries me if we want to keep flags instead of a unified config: a flag wins config that run, but nothing records it, so the next run (redeploy, upgrade) without the flag goes back to the config value.
That's the same drift this issue is about. Should
ate-setuptool warn when a flag overrides a value in the config? Or should install-shaping settings be config-only once the file exists? This model need to be figured outstshrive commentedon Sep 28, 2026
I think that there are a few distinct problems here:
As for recording previously applied values, an applied configuration could be written locally, in a cache, and stored in the infra itself (e.g. config map, perhaps). People probably will want to check in applied values to a repository for operations use (infra-as-code) keeping track of diffs as they are updated.
If the flags are not set, the pre-recorded values get used, otherwise they get overwritten. Total ordering would look like this
default values(nothing specified at all) <cached-config values(previously applied values) <env<--config=<filename(a specific config file to use) <--specific-parameter(a very specific parameter)Lastly you may want to ignore the cached or preset values altogether (similar to no-dev-env) but something like
--no-load-from-cacheHavenXia commentedon Sep 28, 2026
The three-way split makes sense to me, and I believe it should be in GA scope for OSS install. Are you planning to take this on?
Two more thoughts:
on the ordering: with
envabove thecached config, stale export envs in a shell still overrides what was applied last time (previous applied values) , which is the bleed-through you mentioned.For the cache, if the local one conflict with the cluster ConfigMap, cluster copy should win.
stshrive commentedon Sep 28, 2026
I can put something together to capture all of this.
^^ This is a great callout. Will include that as a requirement.
As for env bleed - I absolutely see what you are saying. However, the cached values are interesting because you probably want them to be your "new defaults" but any time you explicitly set something using any other option, it should win. A more inclusive list of where values could come from would be:
defaults<cache(local)<cache(infra)<env<--config<--specific-flag(I am open to eliminating the
envbut this would require rework of the install shim script. Also open to removal of the specific flags but this may require rework of individual components).Alternatively (orthogonally), perhaps an "interactive" install would be useful here (but not required for pre-GA remediation). The install would show the parameter diff and the source of the value (env, cache, flag, etc.) prior to running. If the operator sees something unexpected, they have a chance to abort. This would need to be skippable using a
--headlessor--no-interactive-installflag of some kind.FYI: Taahir Ahmed (@ahmedtd) - Just making sure this doesn't conflict with anything you might be already doing. I'll share anything related to this with you as well.
HavenXia commentedon Sep 29, 2026
Thanks, sounds good to me!
I am ok with
cache(infra) < env, I think we can explictly call out in general install readme and unpgrade runbook to "please start with a a new shell " to avoid the stale env issue.It would also help if ate-setup logged a line whenever an env var overrides a cached value?
Eliminating
envis also a good idea but we need to evaluate the effort.stshrive commentedon Oct 1, 2026
Here is the proposal
EItanya commentedon Oct 1, 2026
One thing I want to point out is that ate-setup seems to be transitioning into the de facto way to install Substrate, which means that the API we create here should be considered as closely as any other in the system in my opinion.
stshrive commentedon Oct 1, 2026
I agree. Note that it is directly informed by the System APIs. That being said, compatibility guarantees should extend to this, especially if upgrades are tied to this pathway as it would need to be backwards compatible with the prior versions.
ate-setup: add the uniform configuration package (agent-substrate#2012)
ate-setup: save used settings locally after installation (agent-subst…
ate-setup: do not record demo and benchmark deploys (agent-substrate#…
ate-setup should record the Substrate version an install used (agent-…
ate-setup: roll ate-api-server once when its environment changes (age…
Upgrade Runbook GA (agent-substrate#1844)