https://cloudposse.com logo
Join Slack
Powered by
Hello :wave: I'm working on getting `aws-ssosync` ...
# atmos
g
Hello šŸ‘‹ I'm working on getting 
aws-ssosync
setup, and I I see you all recently released v2.0.0. I can't find this version published to the open tufu registry. Is this version only meant to be usable with Atmos?
@Veronika Gnilitska FYI
šŸ‘€ 1
e
cc @Dan Miller (Cloud Posse)
It should work with all versions; we've seen other problems with the Tofu registry.
Let me just check if Dan is able to pull it, and if not, we'll escalate.
d
This is a root module /component that isnt published to the tofu registry, so I'm not following. What should be published to the opentofu registry?
e
Hah! Yes, but of course šŸ˜ƒ
@Gerry Laracuente the 
cloudposse-terraform-components
organization is strictly root modules
Root modules are not composable in Terraform or OpenTofu
We pull down root modules (components) in atmos with vendoring or source provisioning
We do not have a child module for SSO sync
g
ah, ok. Really appreciate the quick response here. I'm new to the cloudposse ecosystem, but this makes sense.
np 1
e
In 
atmos
you can pull down root modules like this:
Copy code
components:
  terraform:
    # REMOTE source - vendors from GitHub
    aws-ssosync:
      source:
        uri: "github.com/cloudposse-terraform-components/aws-ssosync.git//src"
        version: "v2.0.0"
      provision:
        workdir:
          enabled: true
      vars:
        ...
v
@Erik Osterman (Cloud Posse) we were able to use previous versions of this component as a child module (it broke after we bumped to v2):
Copy code
module "components_aws-ssosync" {
  source  = "cloudposse/components/aws//modules/aws-ssosync"
  version = "1.536.0"
Was this expected behavior?
e
Perhaps, but they were never designed for that šŸ˜ƒ
If you use a git-source, it should work (vs a registry source in your example above)
but it's not published to the registry
I think you might be pinning to the old 
cloudposse/terraform-aws-components
repo in the example you shared
v
they were never designed for that šŸ˜ƒ
Yeah, I get this. But it was very convenient šŸ˜†
Got it, thanks!
e
šŸ‘ 1
g
I tried that route also, but ran into this error when trying to 
init
:
Copy code
ā•·
ā”‚ Error: Unreadable module directory
ā”‚ 
ā”‚ Unable to evaluate directory symlink: lstat .terraform/modules/components_aws-ssosync/account-map: no such file or directory
ā•µ

ā•·
ā”‚ Error: Unreadable module directory
ā”‚ 
ā”‚ The directory  could not be read for module "iam_roles" at .terraform/modules/components_aws-ssosync/src/providers.tf:16.
ā•µ
That's pointing here: https://github.com/cloudposse-terraform-components/aws-ssosync/blob/main/src/providers.tf#L16 My understanding is that this works as part of the Atmos ecosystem, which goes back to the earlier point that this isn't intended to be composable in Terraform or OpenTofu =/
e
Yes, we are actually working to eradicate the dependencies on the account map.
But for the time being, we can't just rip it out.
My understanding is that this works as part of the Atmos ecosystem
Not atmos, but our commercial reference architecture
šŸ“ 1
Same effect though šŸ˜ƒ
So, with that said, it does seem that upgrading from version 1.5 to version 2 will not be smooth for you.
ā€¢ all our components are built and tested together, which allows us to make assumptions about how things should work ā€¢ all of our child modules should work in any environment; they don't make assumptions
g
appreciate all the quick and insightful responses here šŸ‘
hey guys, I think I found a bug in the newly released v2.0.0. Even though I couldn't consume it as a child module, I still tried to borrow some of your code in my local testing on this. When the lambda job ran, it didn't respect my Google Group Match filter , and instead grabbed all groups...lambda log line:
Copy code
level=info msg="get google groups" queryGroup="*"
This was because the code here creates lambda env vars prefixed with 
SSOSYNC_
But the underlying go code, when run in lambda, doesn't use the prefix. Granted, I don't know golang and might be overlooking something else, but when I remove the prefix in my lambda function, it works as intended. I could file an issue, or even make a PR to your repo if that would be helpful, but I figured I'd just bring it up here while the convo is still fresh and I'm still tinkering on this.
e
cc @Dan Miller (Cloud Posse)
d
@Gerry Laracuente I believe you are correct. That SSOSYNC prefix is left over from the older usage. I'll create a PR
g
yea that's exactly what I did, and exactly the PR I had in mind, thanks!
d
great! np
@Erik Osterman (Cloud Posse) please review when you have a second
2 Views
Open in Slack
PreviousNext
Powered by