tdfs4ds.agentops.config_map¶
tdfs4ds.agentops.config_map
¶
Split the running tdfs4ds configuration into the two halves AgentOps wants.
An AgentOps deployment carries configuration in two places, and the difference between them is a security boundary, not a stylistic one:
config.yaml
Bundled inside the uploaded zip, read by the platform at deploy time.
Committed to source control. Anything written here is visible to everyone
who can read the archive.
runtime_config
A dict in the deployment payload, injected into the pod's environment at
deploy time. Never written to disk by us, never in the zip.
A user reading the AgentOps notebooks has no way to know which of tdfs4ds's ~60
TDFS4DS_* settings belong on which side — the notebooks predate tdfs4ds and
name only OPENAI_* / TD_*. Getting it wrong means either a broken pod or
a credential in a zip file.
The split is derived, never asked. :mod:tdfs4ds.config already answers the
question for its own .env export: :func:~tdfs4ds.config._is_secret knows
what a credential is, and _PASSTHROUGH_ENV_VARS knows what lives only in the
environment. Those are imported rather than re-derived, deliberately — a second
copy of "is this a credential?" is exactly the kind of duplicated authority that
goes stale silently and leaks the thing it was written to protect.
Three destinations:
drop
SERVE_* — the platform is the server, so the tdfs4ds HTTP layer's
toggles are meaningless in a pod and would only mislead whoever reads the
file. CHROMA_* when the backend is 'teradata', for the same reason.
config.yaml
Everything else that is neither secret nor environment-specific.
runtime_config
Secrets, plus the connection and Vector Store auth variables. The latter are
not all secret (TD_HOST is not), but they identify a deployment, not a
configuration: baking them into a committed file is how a package built
against dev silently points at dev forever.
_PASSTHROUGH_ENV_VARS
module-attribute
¶
_PASSTHROUGH_ENV_VARS = frozenset({'TD_HOST', 'TD_USERNAME', 'TD_PASSWORD', 'TD_LOGMECH', 'TD_DATABASE', 'TD_ENCRYPT', 'TD_LOGDATA', 'SERVE_PORT', 'SERVE_BUILD_INDEX', 'SERVE_CHATBOT', 'SERVE_CHATBOT_PORT', 'SERVE_DOCS', 'SERVE_DOCS_PORT', 'SERVE_ROOT_PATH', 'SERVE_MCP_URL', 'SERVE_DEFAULT_VIEW', 'SKILLS_FOLDER', 'VECTOR_STORE_AUTH_BASE_URL', 'VECTOR_STORE_AUTH_AUTH_TOKEN', 'VECTOR_STORE_AUTH_PAT_TOKEN', 'VECTOR_STORE_AUTH_PEM_FILE', 'VECTOR_STORE_AUTH_USERNAME', 'VECTOR_STORE_AUTH_PASSWORD', 'VECTOR_STORE_AUTH_CLIENT_ID'})
_REQUIRED_RUNTIME
module-attribute
¶
_REQUIRED_RUNTIME = {'service': frozenset({'TD_HOST', 'TD_USERNAME', 'TD_PASSWORD'}), 'jwt': frozenset({'TD_HOST'})}
STORE_ATTRS
module-attribute
¶
_is_secret
¶
True when attr names a credential that must never be written in clear.
_value_of
¶
Current value of attr: an override first, else module config or env.
Pass-through variables are never module attributes — they are read straight
from os.environ by the serve layer and reconnect — so they have to be
looked up there or they would silently export as unset.
_is_empty
¶
True when value carries no configuration.
Mirrors config._is_empty's intent: False and 0 are real settings
and must survive, so this never tests plain falsiness.
classify
¶
Return 'config', 'runtime' or 'drop' for one setting.
store_overrides
¶
Build the :data:STORE_ATTRS override mapping from explicit arguments.
Only arguments actually given appear, so a caller that names just the database does not blank out the rest.
split_config
¶
Split the running configuration into the AgentOps halves.
Parameters¶
backend : str, optional
Vector store backend to classify against. Defaults to the running
tdfs4ds.VECTOR_STORE_BACKEND.
overrides : dict, optional
Values that win over the session, keyed by bare attribute name — see
:func:store_overrides. Used to state the deployment's feature store
explicitly instead of inheriting whatever the session happened to have.
Returns¶
dict
{"config": {ENV_NAME: value}, "runtime": {ENV_NAME: value},
"dropped": [ENV_NAME], "missing_runtime": [ENV_NAME]} where every key
is the full TDFS4DS_-prefixed environment variable name.
``missing_runtime`` names the **required** runtime variables that are
not set in this session — the deployment must supply them, and the
caller surfaces them rather than letting the pod discover it. An unset
*optional* runtime variable is simply absent, not a finding.