Repository navigation
fix: emit deployment contract v4 - #110
Merged
Merged
Conversation
The release assembles dfe-transform-vector's thin chart from the contract this binary emits, on scalo-service 2.14.3. This moves the contract to v4 so that chart renders the same as dfe-infra's fixture for this app. - scalo 2.14.1 -> 2.14.3, which writes contract v4. - The contract carries a 120 s startup budget, kubernetes.io/h2c on the push port, writable paths data at /var/lib/vector and run at /var/run/vector, requests 100m/128Mi, limits 500m/512Mi, a 90 s grace, the default security context and no singleton. The description drops ".dev". - KEDA scales on CPU alone. The library's lag trigger read config.kafka.*, which this app does not have, so the library refused to render it. - The Kafka Secret mounts into DFE_TRANSFORM_SOURCE_SASL_* and DFE_TRANSFORM_SINK_SASL_*, the names the app reads, in place of bare KAFKA_SASL_* names nothing read. sasl.secret_dir leaves the default config. - DFE_TRANSFORM_KAFKA_SECURITY_PROTOCOL naming SSL turns source and sink TLS on. It never turns them off. - Config::load no longer calls dotenvy::dotenv(), which loaded the first .env in any parent directory. scalo's cascade now reads ./.env and nothing above it, and dotenvy moves to dev-dependencies. - The committed chart and the tests that pinned it go. emit-chart stays and /chart/ is gitignored. - .hyperi-ci.yaml turns the helm release on with contract: emit and library 2.14.3, and drops build.type. - Dockerfile and docs/config-schema.* regenerated. README, docs and the config.example.yaml header follow.
catinspace-au
added a commit
to hyperi-io/dfe-infra
that referenced
this pull request
Oct 8, 2026
The 2.2.0 chart derived dfe-transform-vector's TLS switch into its config file from kafka.securityProtocol. The thin chart has no such derivation, so the bus profiles hand the protocol to the app's flat env instead, and the app turns TLS on for both endpoints when it names SSL (hyperi-io/dfe-transform-vector#110). - profile-single and profile-scale set DFE_TRANSFORM_KAFKA_SECURITY_PROTOCOL from kafka.securityProtocol, as vrl's do. - apps.yaml lists config.source.tls.enabled and config.sink.tls.enabled as vector's deployment-owned paths, supplied by that env. Both chart copies regenerated. - The weave gate accepts the new env on vector's bus profiles, with the reason.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
Released in v1.0.46 -- https://github.com/hyperi-io/dfe-transform-vector/releases/tag/v1.0.46 |
catinspace-au
added a commit
to hyperi-io/dfe-infra
that referenced
this pull request
Oct 9, 2026
The 2.2.0 chart derived dfe-transform-vector's TLS switch into its config file from kafka.securityProtocol. The thin chart has no such derivation, so the bus profiles hand the protocol to the app's flat env instead, and the app turns TLS on for both endpoints when it names SSL (hyperi-io/dfe-transform-vector#110). - profile-single and profile-scale set DFE_TRANSFORM_KAFKA_SECURITY_PROTOCOL from kafka.securityProtocol, as vrl's do. - apps.yaml lists config.source.tls.enabled and config.sink.tls.enabled as vector's deployment-owned paths, supplied by that env. Both chart copies regenerated. - The weave gate accepts the new env on vector's bus profiles, with the reason.
catinspace-au
added a commit
to hyperi-io/dfe-infra
that referenced
this pull request
Oct 9, 2026
* fix: declare deployment-owned config in apps.yaml dfe-engine refuses a write to a config path the deployment sets over the overlay, and names what sets it. That list now lives here as data, beside the file sets the thin charts mount, and a test holds it to argocd/values/apps. - apps.yaml gains deployment_owned and deployment_owned_when per app, describing the integration values and the dfe-extras env ConfigMaps. - File sets move to fileSets.<set>.files, with the integration mountPath as mount_path. dfe-transform-vector's enrichment set drops entries_path, a key that app never reads. - composition.py --write-catalogue and --check-catalogue cover the dfe-extras copy as well as the dfe-engine chart's. - scripts/tests/test_deployment_owned.py fails when the integration values set a configOverrides leaf or an app-config env var apps.yaml does not list, when apps.yaml names a supplier nothing sets, or when a file set is not the chart's fileSets entry. * fix: own listener binds and gate archive targets Each receiver, fetcher and elastic listener address is deployment-owned through a "contract port <name>" supplier: the contract opens that port on the Service and the probes, so an overlay that moves the bind takes the listener off it. The archiver's destination, S3 endpoint and S3 bucket are owned only once the deployment names a local path or a store, since each renders empty until then and the engine's value stands. test_deployment_owned now checks that a configOverrides supplier names the same path, that every listener a contract binds is listed, and that every app the engine writes config for has integration values. test_catalogue_reaches_the_chart renders each file set and the config block through the chart the appset deploys and looks for a probe value. The file sets are expected to fail while the appset deploys the dfe-common charts, which mount no fileSets. * fix: pass the Kafka protocol to vrl on the bus The 2.2.0 chart derived dfe-transform-vrl's TLS switch into its config file from kafka.securityProtocol. The thin chart has no such derivation, so the bus profiles hand the protocol to the app's flat env instead, and the app turns TLS on for both endpoints when it names SSL (hyperi-io/dfe-transform-vrl#97). - profile-single and profile-scale set DFE_TRANSFORM_KAFKA_SECURITY_PROTOCOL from kafka.securityProtocol, the same value elastic and the archiver read. - apps.yaml lists config.source.tls.enabled and config.sink.tls.enabled as deployment-owned, supplied by that env. Both chart copies regenerated. - The weave gate accepts the new env on the bus profiles, with the reason. * fix: pass the Kafka protocol to vector on the bus The 2.2.0 chart derived dfe-transform-vector's TLS switch into its config file from kafka.securityProtocol. The thin chart has no such derivation, so the bus profiles hand the protocol to the app's flat env instead, and the app turns TLS on for both endpoints when it names SSL (hyperi-io/dfe-transform-vector#110). - profile-single and profile-scale set DFE_TRANSFORM_KAFKA_SECURITY_PROTOCOL from kafka.securityProtocol, as vrl's do. - apps.yaml lists config.source.tls.enabled and config.sink.tls.enabled as vector's deployment-owned paths, supplied by that env. Both chart copies regenerated. - The weave gate accepts the new env on vector's bus profiles, with the reason.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
DFE deploys dfe-transform-vector from a thin chart that hyperi-ci assembles at release, from the contract this binary emits, on the scalo-service library chart. This moves the contract to v4 so that chart renders the same as dfe-infra's fixture for this app.
kubernetes.io/h2con the push port, writable pathsdataat/var/lib/vectorandrunat/var/run/vector, requests 100m/128Mi, limits 500m/512Mi, a 90 s grace, the default security context and no singleton.DFE_TRANSFORM_SOURCE_SASL_*andDFE_TRANSFORM_SINK_SASL_*, the names the app reads.every_contract_secret_env_var_reaches_the_configholds each name to the field it spells.DFE_TRANSFORM_KAFKA_SECURITY_PROTOCOLnaming SSL turns source and sink TLS on, and never off, as the 2.2.0 chart did in its config file.Config::loadno longer callsdotenvy::dotenv(), which walked up every parent directory. scalo's cascade now reads./.envonly.a_dotenv_in_a_parent_directory_is_not_loadedruns the binary to prove both halves.chart/and the tests that pinned it go.emit-chartstays and/chart/is gitignored..hyperi-ci.yamlturns the helm release on withcontract: emitand library2.14.3, and dropsbuild.type.The emitted contract validates against the library's v4 schema with 0 errors. Through dfe-weave
assemble()on scalo-service 2.14.3 it renders byte-identical to the fixture's render with empty values and withconfig.source.transport=direct.The dfe-infra side sets the protocol env on the bus profiles and lists the two TLS paths as deployment-owned (hyperi-io/dfe-infra#573).
Nothing is released by this PR.