Dear community, we’ve been asked a lot about programmatic interactions with Airbyte's configurations. We are working on a CLI project called 

octavia

 octavia partying for which we wrote a tech spec summarized in this deck. Feel free to give feedback directly by commenting on the slides! We’ll start coding soon.  (cc. @Scott Pedersen @Bruno @Valentin Nourdin @Thomas CLAVET @Simbazz @Sebastien Mamessier @Nathan Atkins @Tuan Nguyen  I think you're going to be interested in this!)

This looks awesome @[DEPRECATED] Augustin Lafanechere. Thanks so much for sharing 🙂

Thanks for sharing @[DEPRECATED] Augustin Lafanechere. This is definitely something relevant to us and I’d be happy to try it out once it’s ready.

@Alexandre Martins @Henk van Dyk @Sebastià Galmés

Awesome news 🙂

Love this idea -- my company is currently in the process of writing out own wrapper around config files which uses the airbyte api to update the configs!

looks good , it's Awesome

Definitely interested 😄

cc @Robert Stolz

Nice! we are also working on a wrapper around the api that uses yaml configs

This....looks a lot like what a terraform provider would be. I do like it though. We needed some way to plug into our CI/CD pipelines and make sure our various connections are managed in code. This will make that possible. 👍

@Jason Reslock you're right, and the terraform workflow was indeed an "inspiration" while working on this spec. We evaluated what it would take to create a TF provider with the same features, but the dynamic nature of our connector's schema made it hard to fit in TF SDK which is not yet supporting dynamic pseudo types.

This is really cool. I’ve been looking for a way to better manage configs in airbyte. Keep us posted 👍

Terraform supports k8s CRD, so I see no reason why it should not support dynamic objects and why we should not develop a terraform provider. See: https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs/resources/manifest

you are right @Kamil Breguła but the CRD support is made possible by a lower level terraform sdk which adds a lot of overheads and complexity, we feel like it's more straightforward at the moment to work on a cli that is more ubiquitous