-
Notifications
You must be signed in to change notification settings - Fork 159
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
DynamoDB migration errors #4
Comments
And another failure even just on a
|
I wonder if there is a version mismatch. Can you verify that the lumi and terraform-bridge revisions match the latest? |
They should be the same sources as what's on my dev machine. I'm not synced to latest of everything, but I was in a working state across all the repos locally, and the same pulumi sources were failing inside the deployment container image. I will try brining everything up to date locally (I need to do that anyway), but it's not clear why these errors could be related to out-of-date lumi or terraform-bridge components. Any tips on debugging these sorts of issues? Does the combination of the DynamoDB migration failure and the GetRoleInput failure suggest any root cause to you? |
I've definitely had lots of problems getting versions to line up myself when bringing up the Travis CI work, primarily due to dep resolving to different versions. The GetRoleInput error suggests that the GroupName field is missing on the call to Get, which should only happen if the role name wasn't mapped properly. This could be a missing AutoNameInfo for "role_name" -- I can't remember offhand but can take a look a little later -- however there have definitely been lots of bug fixes that mean the name changes may or may not have been working at a particular commit back in time. |
Okay - I think I've gotten this working now by bringing everything up to date. I'm still unclear on what the root cause here was - but I'm no longer blocked for now. |
# This is the 1st commit message: Fix import resources with provider default tags We have special logic around applying default provider tags to resources. This logic only applied to the `Check` call which means it was not applied when you were importing resources. This PR extends that logic to also run during the `Read` call. fix #4030, fix 4080 # This is the commit message #2: skip test # This is the commit message #3: fixing test # This is the commit message #4: Adding more tests # This is the commit message #5: Upgrade pulumi-terraform-bridge to v3.86.0 (#4160) This PR was generated via `$ upgrade-provider pulumi/pulumi-aws --kind=bridge --pr-reviewers=guineveresaenger`. Fixes #4091 Fixes #4137 --- - Upgrading pulumi-terraform-bridge from v3.85.0 to v3.86.0. - Upgrading pulumi-terraform-bridge/pf from v0.38.0 to v0.39.0. # This is the commit message #6: chore: run upstream provider-lint (#4120) This adds a step for running the upstream `provider-lint` make target. As part of this I had to fix some of the patches which violated some lint rules. **0009-Add-ECR-credentials_data_source.patch** - `ForceNew` does not apply to data sources **0032-DisableTagSchemaCheck-for-PF-provider.patch** - Schema have to have a `Type` - Also needed to add a ignore for `S013` which forces `Computed`, `Optional` or `Required` to be set. Looks like it can't recognize the `tagsComputed` var **0034-Fail-fast-when-PF-resources-are-dropped.patch** - Added a lint ignore for a rule which doesn't allow panics **0050-Normalize-retentionDays-in-aws_controltower_landing_.patch** - This test doesn't actually need a region or partition so replacing with a placeholder closes #4110 # This is the commit message #7: fix: CVE-2024-24791 (#4175) Fixes #4163 Upgrades minimally required Go versions to those unaffected by CVE-2024-24791.
I can't figure out what's going on here. If I deploy an example that uses DynamoDB through the containerized Ubuntu image I see
lumi deploy
failures inside the Terraform bridge. But I can't reproduce these locally. I believe versions of everything are the same - but very well could be that something is different (currently hard to create a stable environment with the complex sets of static and dynamic dependencies).Here's the error I get (some of this may be out-of-order due to how the deployment service currently prints stdout/stderr):
Note the attempt to migrate state from v0 to v1, then the failure to read the state (which appears to have been passed as
nil
).Any ideas what might be going on here?
For reference, here's current Dockerfile contents to try to create a deployment environment:
The text was updated successfully, but these errors were encountered: