-
Notifications
You must be signed in to change notification settings - Fork 914
chore: persist template import terraform plan in postgres #17012
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
The purpose of this is not widely known, so just dropping a note. The output of The phasing in of this new feature is that it will live alongside the existing flow for some time. So this new table will be |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is all looking good. I am wondering if in the future we will need to implement a way to garbage collect up this data.
We might be able to do some trimming in the future, but keeping the raw plans gives us the most flexibility in the future.
EDIT: We store the original TF too, so versions are already bloated
Adds plumbing to persist terraform plan data from template import provisioner builds.
After some deliberation, I went with storing what I have called the
cached_plan
in a separate table because these values are incredibly large, thetemplate_versions
table already has a lot of columns, and a lot of queries usetemplate_version.*
to get those many columns. Accidentally including thecached_plan
column in those queries would be very undesirable, and this value mostly exists for future use on the backend. I don't think this is the sort of thing we would ever actually want to send to a client, except maybe a page for debugging the current state.This also means that we can track it's
updated_at
time separately quite easily, since we're planning on letting it be "refreshed".Closes #17050