brave-angle-33257
10/16/2018, 7:14 PMbitter-oil-46081
10/16/2018, 9:57 PMgovendor
(which the upstream terraform provider uses to manage dependencies) and dep
(which Pulumi uses to manage dependencies) makes it hard to ingest updates from upstream. Ideally we'd have an automated process to do this, but the problem is that every-time we've gone to do this we've had to have manual intervention to get something that works.
@stocky-spoon-28903 Is going to start looking at how we can actually stop having this class of problems, but for now the problem is basically that we can't take in new code from upstream so we can't run tfgen over it. The problem is that tfgen and tfbrdige don't work on the terraform provider binary. Instead, we need the correct set of terraform sources (plus dependencies) as well as some pulumi sources to both build tfgen and the pulumi version of the provider and getting a consistent set of sources is not easy.brave-angle-33257
10/16/2018, 10:09 PMbig-piano-35669
brave-angle-33257
10/16/2018, 10:30 PMchilly-crayon-57653
brave-angle-33257
10/18/2018, 8:12 PMbitter-oil-46081
10/19/2018, 12:40 AMI was thinking we could have our automations deploy using standard cloud backend but then maybe export the state file and save it in a versioned object store after each deploy. Is that a feasible failsafe?That would work. We do something similar for our key services where after an update we export the checkpoint and store it in a seperate versioned S3. In the disaster recovery case we'd pull down the checkpoint from the bucket, use
pulumi login --local
to connect to the local backend and then pulumi stack import.brave-angle-33257
10/19/2018, 1:09 AM