Dear community, we’ve been asked a lot about progr...
# announcements
Dear community, we’ve been asked a lot about programmatic interactions with Airbyte's configurations. We are working on a CLI project called 
 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!)
octavia loves 25
📈 5
👍 27
👋 2
yay 3
airbyte 3
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 😄
👍 1
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.
👍 4
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:
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