Deploying aws-ssosync

[dukarc]

I have enabled the vendor and I can see that the component (ssosync) was downloaded after atmos vendor pull.
I also put my ssoconfig under stacks/catalog. However, atmos doesnt see it.How do I deploy this component? We have imported the manifest form the catlog into stac

[milldr]

Is the component added to a stack? https://docs.cloudposse.com/learn/component-development/#-add-component-imports

Can you describe the component? https://atmos.tools/cli/commands/describe/component/

[cmarquezrusso]

The component was added to stacks/orgs/vbpt/core/root/global-region/baseline.yaml

When I run atmos component describe, I get an output with the parameters defined on aws-ssosync.yaml. However, when I prepare the plan, it shows this:

Executing command:
atmos terraform plan aws-ssosync --stack core-gbl-root

WARN detected 'TF_PLUGIN_CACHE_DIR' set in the environment; this may interfere with Atmos's control of Terraform.

Initializing the backend...

Successfully configured the backend "s3"! OpenTofu will automatically
use this backend unless the backend configuration changes.

Initializing provider plugins...

OpenTofu has been successfully initialized!
Switched to workspace "core-gbl-root".
Acquiring state lock. This may take a few moments...

No changes. Your infrastructure matches the configuration.

OpenTofu has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
╷
│ Warning: Value for undeclared variable
│ 
│ The root module does not declare a variable named "schedule_expression" but a value was found in file
│ "core-gbl-root-aws-ssosync.terraform.tfvars.json". If you meant to use this value, add a "variable" block to the
│ configuration.
│ 
│ To silence these warnings, use TF_VAR_... environment variables to provide certain "global" settings to all configurations
│ in your organization. To reduce the verbosity of these warnings, use the -compact-warnings option.
╵
╷
│ Warning: Value for undeclared variable
│ 
│ The root module does not declare a variable named "region" but a value was found in file
│ "core-gbl-root-aws-ssosync.terraform.tfvars.json". If you meant to use this value, add a "variable" block to the
│ configuration.
│ 
│ To silence these warnings, use TF_VAR_... environment variables to provide certain "global" settings to all configurations
│ in your organization. To reduce the verbosity of these warnings, use the -compact-warnings option.
╵
╷
│ Warning: Values for undeclared variables
│ 
│ In addition to the other similar warnings shown, 14 other variable(s) defined without being declared.
╵

[milldr]

No changes. Your infrastructure matches the configuration.

This says there arent any changes. Does the component actually have anything in it? It should look something like this:

components/terraform/aws-ssosync
├── README.md
├── component.yaml
├── context.tf
├── iam.tf
├── main.tf
├── outputs.tf
├── providers.tf
├── variables.tf
└── versions.tf

[milldr]

and does the name of the component starting after your component base path components/terraform match exactly the name of the component in stacks, aws-ssosync? Either the name of the stack or passed with metadata.component

[dukarc]

@milldr

1. Able to run plan/apply on aws-ssosync Component!

We were able to get the component to be recognized after adding the following lines to the bottom of stacks/orgs/vbpt/core/root/global-region/identity.yaml. This was pretty challenging for us to figure out and we couldn't see anywhere in documentation on how we should have found to do this. It was purely hacking on things that made it work.. alas we aren't sure this is the optimal pattern here?

    aws-ssosync:
      metadata:
        component: aws-ssosync/1.536.0

2. AWS-SSOSYNC component latest version is broken

Alas it looks like the aws-ssosync component has an issue as AWS has shifted things and no longer supports the Go1.x runtime.

when attempting to run
atmos terraform apply aws-ssosync --stack core-gbl-root

get this error

│ Error: creating Lambda Function (vbpt-core-gbl-root-aws-ssosync): operation error Lambda: CreateFunction, https response error StatusCode: 400, RequestID: 4a422fff-aefd-4fff-81cd-e6c712b9867d, InvalidParameterValueException: The runtime parameter of go1.x is no longer supported for creating or updating AWS Lambda functions. We recommend you use a supported runtime while creating or updating functions.
│ 
│   with aws_lambda_function.ssosync[0],
│   on main.tf line 67, in resource "aws_lambda_function" "ssosync":
│   67: resource "aws_lambda_function" "ssosync" {

We have attempted to convert to provided.al2 runtime by updating components/terraform/aws-ssosync/1.536.0/main.tf runtime ... alas it looks like we would need to recompile the lambda function to get this fully working. Its a bit too much for me to take on while still ramping on these things. Is this something cloud posse could help us look at?

3. Best path for us forward for now while we are stuck?

If we are stuck here.. could we just move onwards without getting aws-ssosync in place to port auth google groups over? I.e. could we just manually create the groups for now and circle back to aws-ssosync later?

[milldr]

1. Able to run plan/apply on aws-ssosync Component!

great! It looks like you're vendoring or creating the component in a sub directory, ie components/terraform/aws-ssosync/1.536.0. That's completely fine to do if you choose, but as you've found you will need to tell Atmos the path to the component with metadata.component (since aws-ssosync does not match the real path).

Please see https://atmos.tools/core-concepts/vendor/vendor-manifest/#vendoring-multiple-versions-of-components

2. AWS-SSOSYNC component latest version is broken

We can definitely help, but only through a support engagement. While open source contributions are always welcome, we prioritize billable work—so we’ll likely address this in the future, but we can’t commit to a timeline unless it’s covered under a support plan.

3. Best path for us forward for now while we are stuck?

Yes you can skip the automatically provisioning for now and manually create the groups and users. Keep in mind they names (and capitalization) must match exactly

[dukarc]

1. Got it ... thank you didn't know we were using multiple versions of components here.

I see changing our vendor.yaml file from here .. changes the need to use metadata.component

apiVersion: atmos/v1
kind: AtmosVendorConfig
metadata:
  name: vendor-config
  description: Atmos vendoring manifest
spec:
  sources:
    - component: "aws-ssosync"
      source: "github.com/cloudposse/terraform-aws-components.git//modules/aws-ssosync?ref={{.Version}}"
      version: "1.536.0"
      targets:
        - "components/terraform/{{.Component}}/{{.Version}}"

to

apiVersion: atmos/v1
kind: AtmosVendorConfig
metadata:
  name: vendor-config
  description: Atmos vendoring manifest
spec:
  sources:
    - component: "aws-ssosync"
      source: "github.com/cloudposse/terraform-aws-components.git//modules/aws-ssosync?ref={{.Version}}"
      version: "1.536.0"
      targets:
        - "components/terraform/{{.Component}}" # <-- CHANGE HERE

[dukarc]

Fyi @milldr we were able to get the component working on the latest ssosync after a few changes. Happy to share with someone what we did. Right now its living on custom updates on local for us.

tl;dr

most of the work was changing the environment variables .. and needing to leverage secret manager vs SSM