That's how data sources work for serious uses as well.
For example - get AWS AMI where we can pin it or let it be latest.
> the spirit of immutable infrastructure
Immutable means changes recreate the resources. Not that that there won't be any changes. Mutable infra is where we keep patching the same resource and potentially end up in a state where we are not able to recreate it.
I think they mean "deterministic," not "immutable"
Yeah on further reflection maybe the "immutable" part of this is that I never use the Spotify UI to modify my playlist - it only gets changed during terraform apply phases, which may change the playlist in random ways on each re-apply.
This is very much the spirit of 2022: You don't change anything, but a butterfly flaps their wings in Tokyo, and now your build is broken.
And you can't ask the butterfly anything unless you sign an NDA.
Indeed. If you don't like it, prepare to get into a lot of arguments. EKS/Helm providers in combination with controllers are wild. It forces you to understand every little facet your cluster if _anything_ goes wrong.
Maybe, but the official serious providers do stuff like this, too. Consider the feature that lets you automatically use the latest Linux or Windows AMI; it changes without you touching your .tf file.
There's nothing that says it has to be immutable. It's not uncommon to perform similar searches in e.g. AWS to select the latest version of some AMI or another resource that is subject to change, and applying with no changes to the Terraform code would update the resource. This isn't really "infrastructure" either. It's a neat use case.
Moreover, you can pair it with drift detection (available in i.e. Spacelift[0]), and have it automatically detect when a data source changes (and apply the resulting infra changes).
Very common scenario with lots of neat use cases around it. One of the more interesting ones - use a GitHub pull request listing data source to create an ephemeral environment for each PR.
Disclaimer: Software Engineer at Spacelift
Just received (I hope it was by chance) a cold mail from your company today. If I might be interestes by your post here, now I'm not anymore.
OK, here's my 2020 playlist materialized as code so that I can't accidentally clear it out and lose a track with no trace!:
https://open.spotify.com/playlist/6NO3v396w2tZc6MnXSKNPM
https://github.com/mherdeg/learn-terraform-spotify/blob/main...
Whoops, nope, it's https://open.spotify.com/playlist/4xE4NPeiQeHNjeLL5fvYrn.
The example directive "spotify_search_track" runs a server-side search on Spotify and returns a list of results, which you can use to populate a playlist.
This is like … very cool, but also isn't it a little against the spirit of immutable infrastructure? Every time Spotify re-ranks their search results my terraform apply will populate different songs into my playlist, without anything changing in my main.tf in source control.