Open bernardhalas opened 3 years ago
There's one thing I'd like to discuss here - I don't see the need for a Claudie Terraform provider. At the moment, I'd see that as pointless overengineering. I think the InputConfig is already technically IaC. We can talk about this deeper at a later time.
We can discuss asynchronously even now.
I'm not saying that the TF provider is very important right now. But in general, how are our customers gonna interact with the platform? I see just 2 ways. GUI and a TF provider (unless they have some advanced automation and would like to plug directly into our API). We all agree that IaC is a good approach to run things.
BTW, I'm fully OK with reducing the scope just to the config file atm.
Adding some additional ways users could apply changes to their inputConfig, for inspiration:
curl
HTTP request (POST?) to the front end ingress, e.g. curl -F ‘data=@path/to/local/file’ UPLOAD_ADDRESS
claudie --instance 10.24.24.1 --token 58435437dsfxf132 apply -f inputConfig.yaml
.These approaches are both simpler, and easier to implement than a Terraform provider. They are also more convenient for the customer, e.g. easily automated and made part of a CI/CD pipeline. Lastly, I suspect that operating Claudie via a Terraform provider would bring many unexpected issues.
By the way, whatever way we'll choose, we'll have to think about authentication of a user to the platform. And even more so if the platform is supposed to be multi-tenant (2 or more different customers per claudie instance).
P.S. I think we both agree that HTTP REST API is a good solution, though :)
I see things quite differently now in contrast to the above comments.
Anyway, I think a config-file injection is a good way to start. Actually, how about a K8s configmap volumemount into one of the Claudie components? That would be a very welcome thing to do relatively soon, even for the sake of the MVP. What do you think @bernardhalas ?
Motivation Define interfaces (user or robotic ones) through which the clients can interact with platform. I assume we will need