A plea for a declarative api for provider/profile updates

[mroark1m]

Currently it seems to me like provider and profile updating is a painful exercise that requires you to have a lot of knowledge about the state of the system in order to update it. This complicates simple source control of profiles and providers definitions outside of the built-ins and makes automation of creating and updating those things unnecessarily hard.

For profiles, You have to fetch the file out using the tool, eliminate the providers (or ask it to), and update a resource version just to update the profile.

Additionally, you have to precheck if the thing exists before you create it because updating it is a whole separate command. So any automation I want to build for creating this now has to handle a check if/else around creating or updating each object and I have to remember to update the file 'just so' and make sure also that I do things in the correct order because of dependencies.

IMHO, a declarative and idempotent style is preferable. I should be able to declare my provider and profile in a single file and just say 'make it so' and then, assuming things can be applied, that's what I get. If it needs to be created, create it, if it needs to be updated, update it. Handle the dependencies in the order needed. See terraform for reference.

If I can just update a single file in place rather than importing and exporting potentially different and multiple files, then the whole problem with stale files mentioned in the docs goes away, there is no extra copy to get stale. There is just the one file that says declaratively what I want. If I want to version it, I'll version it in a version control system.

Another weird thing here is the lint command rejects profiles if they already exist. How do you lint a file that has a change and is already created? Will you provide also an update-lint command? Linting does not and should not affect the runtime system so why check it at all? No other tool I know of lints against what is in the runtime system, to me this violates the principle of 'least surprise'. At most that should be a warning or an opt-in check or something.

I grant that I have not thought through all the aspects regarding secret rotation or other things that have to be stateful, but those should probably be kept outside the declarative definition.

[johntmyers]

Thanks for the feedback. Would you be interested in putting some more concrete ideas together on a more ergonomic approach?

We haven't gotten a lot of concrete feedback on providers v2 so this is the time to make improvements before we stabilize the APIs for beta and make providers v2 the default.

[mroark1m]

I can give it a shot, I'll see what I can come up with.