helm: support passing raw config in teleport-kube-agent#20129
helm: support passing raw config in teleport-kube-agent#20129
teleport-kube-agent#20129Conversation
|
@hugoShaka Hello! Thanks a lot for this great feature - i need this exact functionality in my project right now. Do you happen to know when the helm chart with this feature will be released? |
|
@Jasstkn this change will be part of the v12 chart. We are currently validating the v12 release. If no major issue is detected, it should be released in a couple of weeks. Once I'm finished with the test campaign (next week), I'll look at backporting the feature to v11 and v10. The feature will then be available after the next bugfix/minor release. |
I was trying to install the devel version of the helm-chart hoping that the feature was already there. But it looks like development versions are published in some different way. Do you know if any of the dev versions contain this functionality? or would it be possible to publish it earlier under dev version so I can continue with my tests? |
|
Dev builds are generated on-demand by devs themselves. If you want to play with the feature, you can use the version from the We don't officially support this installation because we might introduce breaking changes and bugs on |
Thanks, that works. This feature is available under 12.0.0-alpha.1 version. |
This commit implements arbitrary configuration passing to Teleport, like what was done for the `teleport-cluster` in #18857. This allows users to deploy services or set fields the chart does not support. The huge snapshot diffs are caused by order changes in the config (the YAML export orders keys alphabetically). I validated that the old and new snapshots were strictly equivalent with the following python snippet: ```python import yaml import pathlib import deepdiff old = yaml.safe_load(Path("./config-snapshot.old").open()) new = yaml.safe_load(Path("./config-snapshot.new").open()) old_content = { k: yaml.safe_load(yaml.safe_load(v[1])["data"]["teleport.yaml"]) for (k,v) in old.items() } new_content = { k: yaml.safe_load(yaml.safe_load(v[1])["data"]["teleport.yaml"]) for (k,v) in new.items() } diff = deepdiff.DeepDiff(old_content, new_content) print(diff) ```
…20449) This commit implements arbitrary configuration passing to Teleport, like what was done for the `teleport-cluster` in #18857. This allows users to deploy services or set fields the chart does not support. The huge snapshot diffs are caused by order changes in the config (the YAML export orders keys alphabetically). I validated that the old and new snapshots were strictly equivalent with the following python snippet: ```python import yaml import pathlib import deepdiff old = yaml.safe_load(Path("./config-snapshot.old").open()) new = yaml.safe_load(Path("./config-snapshot.new").open()) old_content = { k: yaml.safe_load(yaml.safe_load(v[1])["data"]["teleport.yaml"]) for (k,v) in old.items() } new_content = { k: yaml.safe_load(yaml.safe_load(v[1])["data"]["teleport.yaml"]) for (k,v) in new.items() } diff = deepdiff.DeepDiff(old_content, new_content) print(diff) ```
This PR implements arbitrary configuration passing to Teleport, like what was done for the
teleport-clusterin #18857. This allows users to deploy services or set fields the chart does not support.The huge snapshot diffs are caused by order changes in the config (the YAML export orders keys alphabetically). I validated that the old and new snapshots were strictly equivalent with the following python snippet: