-
Notifications
You must be signed in to change notification settings - Fork 180
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
bbl v9.0.0 {jumpbox-address,outputs} can fail #560
Comments
Some bbl commands like "jumpbox-address" or "outputs" run "terraform output" under the hood. When the working directory points to terraform config files, modern terraform can fail and complain that plugins are not initialized. This happens when either plugins were omitted altogether or when the plugins are for a different architecture (e.g. when consume linux/amd64 bbl-state on a local darwin dev environment). This change set the working directory to the bbl-state so "terraform output" should reliably work independent of the plugin state. Fixes cloudfoundry#560
Some bbl commands like "jumpbox-address" or "outputs" run "terraform output" under the hood. Previously bbl set the working directory of the terraform command to "$BBL_STATE_DIRECTORY/terraform". When the working directory of the terraform command contains terraform config files, modern terraform can fail and complain that plugins are not initialized. This errors occurs when either plugins were omitted altogether or when the plugins are for a different architecture (e.g. when consuming linux/amd64 bbl-state on a local darwin dev environment). The change here sets the working directory to the top-level bbl state directory so "terraform output" will reliably work independent of the plugin state. Fixes cloudfoundry#560
Run terraform output commands with the working directory set to the top-level bbl-state directory rather than the ./terraform subdirectory to allow this command to succeed even with plugins have not been initialized. Fixes cloudfoundry#560
yes i noticed this to. i thought about maby a check if plugins are not there it would do a terraform int again to get the plugins. i also have several tasks where we put |
Run terraform output commands with the working directory set to the top-level bbl-state directory rather than the ./terraform subdirectory to allow this command to succeed even with plugins have not been initialized. Fixes cloudfoundry#560
A simple solution seems to be to just run I had sent an initial PR (#561) along these lines, but closed it after I remembered "remote terraform state", which is possible to do with, e.g., this plan patch. However, the idea in that PR may not be so terrible. After all in bbl 8.4, deleting plugins in that use case was already broken. For "local" state, we are already conditionally running Alternatively, maybe just unconditionally running Conditionally reading state seems complex, and potentially brittle. Maybe one of these other ideas are reasonable. Thoughts? |
Keeps terraform plugins when bbl-ing up the baba-yaga-bbr env. These terraform plugins are now required (as of bbl v9) to run commands like `bbl jumpbox-address` now, which we need to run when generating the drats config. See cloudfoundry/bosh-bootloader#560 for more info.
i think running a i think we can put some logic here https://github.com/cloudfoundry/bosh-bootloader/blob/main/terraform/executor.go#L302 |
Keeps terraform plugins when bbl-ing up the baba-yaga-bbr env. These terraform plugins are now required (as of bbl v9) to run commands like `bbl jumpbox-address` now, which we need to run when generating the drats config. See cloudfoundry/bosh-bootloader#560 for more info.
❓ Is it expected that I'd been experiencing the same issue as described above, and figured that adding the plugins would solve the issue. I'm still getting the same error unless I manually run The
But when I upload my environment repo to a concourse worker with
🤔 Weirdly, terraform itself seems to work:
However, even though I can see that the plugin files are still present in the
After I run |
Adds `terraform init` call to bbl setup in order to ensure that certain bbl commands succeed. See cloudfoundry/bosh-bootloader#560 for more info.
Offhand, it looks like you have plugins for darwin_amd64 but are running We do something similar on our team where we might locally bbl up on our workstations (darwin_{amd64,arm64}) and then consume that bbl state in CI (linux_amd64).
Running terraform directly will fail if your working directory is
bbl currently sets the working directory to the #561 attempted to fix this problem by just changing the terraform working directory to not be #563 attempted to fix this problem by Thinking about this more broadly, I'm not sure why bbl reads terraform state for
|
Runs `terraform init` if we're not deleting the terraform plugins, in order to make sure that all of the relevant plugins have been downloaded (at least for the architecture of the concourse container, likely linux). See cloudfoundry/bosh-bootloader#560 for more info.
Removes the network-lb-gcp plan patch from baba-yaga-bbr. This plan patch has dubious value, and is broken with the new bbl. We should rip it out and see if everything still works. Changes the way that bbr group acquires and releases the lock for the env. Previously, `add_claimed` and `remove` were used, which was creating a whole new lockfile and then deleting it.. not sure why we wanted to do that. So this change switches to using `acquire` and `release`, which should be a valid replacement because we only expect there to be one lock file in this pool. Keeps terraform plugins when bbl-ing up the baba-yaga-bbr env. These terraform plugins are now required (as of bbl v9) to run commands like `bbl jumpbox-address` now, which we need to run when generating the drats config. See cloudfoundry/bosh-bootloader#560 for more info.
Runs `terraform init` if we're not deleting the terraform plugins, in order to make sure that all of the relevant plugins have been downloaded (at least for the architecture of the concourse container, likely linux). See cloudfoundry/bosh-bootloader#560 for more info.
This is a weird case we started seeing with bbl v9.0.0. Typically we store our bbl-state in an s3 bucket without the .terraform plugins, using cf-deployment-concourse-tasks with the default
DELETE_TERRAFORM_PLUGINS=true
param.Most of our bbl state commands like
bbl print-env
just work without issue. But we found thatbbl jumpbox-address
andbbl outputs
fails with this error:Previously this worked in bbl v8.4.111.
The text was updated successfully, but these errors were encountered: