3 ms·

> go straight to the APIs for definitions Do you really think no-one has tried that? The API definitions (even the good ones, like Azure) do not contain suffi

by jen20 3y ago

> go straight to the APIs for definitions Do you really think no-one has tried that? The API definitions (even the good ones, like Azure) do not contain sufficient information to be able to build a declarative tool. Google seem to view their internal annotations about what is mutable or not as some kind of competitive advantage (bizarre). The AWS API is wildly poorly specified for building anything except 1-1 API wrappers. (Cloud Control improves it, but covers few important resources).

verdverm 3y ago
Everything has gaps that need to be filled, the main point is that the object I send is the same shape and schema as the API, same for their responses and the data in the system. TF under the hood is using these APIs through an abstraction. I say "go to the APIs" as (1) bypassing abstractions (2) in CUE, we can import the existing TF resource schemas from the Go types, or from the OpenAPI schemas. There are 2 camps in CUE about how to approach the CUE/TF/Helm/k8s intersection (one for each way) CUE actually offers a really great space to enrich the APIs with the needed information.
- jen20 3y ago
  CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider (whether TF, Pulumi or anything else!) can be generated from a cloud provider API specification. The only cloud that offers a really declarative API at all is Azure, via Resource Manager. For AWS, since most APIs are request-response focused (AttachENI, DetachVolume and so forth), something has to tie all that together to make a resource-focused API.
  - verdverm 3y ago
    > CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider 100% agreement What CUE potentially makes great is going from what the API spec has available to what we need by keeping the enrichments by us in the same space, so we merge or unify into a single space, without having to write code in the imperative sense. You get to stay in a logical space that will ensure what you write remains self consistent. It will catch the gaps and issues earlier. I'm not aware of any config language or other technology that looks to make this processes as good as CUE can, except maybe sprinkling some of that magic LLM dust on the problem too, which CUE will help in double checking as well

by jen20 3y ago

verdverm 3y ago

Everything has gaps that need to be filled, the main point is that the object I send is the same shape and schema as the API, same for their responses and the data in the system. TF under the hood is using these APIs through an abstraction. I say "go to the APIs" as (1) bypassing abstractions (2) in CUE, we can import the existing TF resource schemas from the Go types, or from the OpenAPI schemas. There are 2 camps in CUE about how to approach the CUE/TF/Helm/k8s intersection (one for each way) CUE actually offers a really great space to enrich the APIs with the needed information.

jen20 3y ago
CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider (whether TF, Pulumi or anything else!) can be generated from a cloud provider API specification. The only cloud that offers a really declarative API at all is Azure, via Resource Manager. For AWS, since most APIs are request-response focused (AttachENI, DetachVolume and so forth), something has to tie all that together to make a resource-focused API.
- verdverm 3y ago
  > CUE or any other configuration language is orthogonal to whether or not a meaningful declarative provider 100% agreement What CUE potentially makes great is going from what the API spec has available to what we need by keeping the enrichments by us in the same space, so we merge or unify into a single space, without having to write code in the imperative sense. You get to stay in a logical space that will ensure what you write remains self consistent. It will catch the gaps and issues earlier. I'm not aware of any config language or other technology that looks to make this processes as good as CUE can, except maybe sprinkling some of that magic LLM dust on the problem too, which CUE will help in double checking as well