https://cloudposse.com logo
Join Slack
Powered by
Hey all! I'm having some trouble with vendoring co...
# atmos
l
Hey all! I'm having some trouble with vendoring components from https://github.com/cloudposse-terraform-components. I've got the following `vendor.yaml`:
Copy code
# Vendor manifest for component management
apiVersion: atmos/v1
kind: AtmosVendorConfig
metadata:
  name: component-vendoring
  description: Vendor configuration for infrastructure components

spec:
  # Source specifications
  sources:
    - component: acm
      source: "<http://github.com/cloudposse-terraform-components/aws-{{.Component}}.git?ref={{.Version}}|github.com/cloudposse-terraform-components/aws-{{.Component}}.git?ref={{.Version}}>"
      version: "v2.0.0" 
      targets:
        - "components/terraform/{{.Component}}"
      included_paths:
        - "**/*.tf"
        - "**/*.tfvars"
        - "README.md"
        - "LICENSE"
      excluded_paths:
        - "examples/**"
        - "test/**"
        - ".github/**"
    - component: account-map
      source: "<http://github.com/cloudposse-terraform-components/aws-{{.Component}}.git?ref={{.Version}}|github.com/cloudposse-terraform-components/aws-{{.Component}}.git?ref={{.Version}}>"
      version: "v1.536.1"
      targets:
        - "components/terraform/acm/{{.Component}}"
      included_paths:
        - "**/*.tf"
        - "**/*.tfvars"
        - "README.md"
        - "LICENSE"
      excluded_paths:
        - "examples/**"
        - "test/**"
        - ".github/**"
Which has led to the following directory structure:
Copy code
components/terraform/acm/
├── account-map
│   ├── README.md
│   └── src
|       └── ... Omitted ...
├── backend.tf.json
├── providers_override.tf.json
├── README.md
└── src
    ├── backend.tf.json
    ├── <http://context.tf|context.tf>
    ├── ... Omitted ...
This has the following issues: • All the terraform files are in a 
src/
subdirectory which means I need to reference the components as 
acm/src
. Not a huge deal, just annoying, but leads to the bigger issue below. • The acm component has some sort of implicit dependency on 
account-map
expecting it to be at 
../account-map
. This may be a bug in of itself but my attempt to fix this by vendoring 
account-map
component inside the 
acm
component hasn't worked due to the vendoring putting the files inside 
src/
Is there any way to prevent vendoring placing the files under the 
src/
directory? If not is the expected way to use vendored components by defining them as 
component: acm/src
? Or is this just a bug in the 
acm
component that needs to be fixed?
e
append 
//src
to vendor a subfolder
👍 1
l
Perfect, thanks Erik!
j
Crazy idea...why not support import CloudPosse components like this?
Copy code
import:
  - cloudposse/aws-eks-argocd:v2.4.1
The above would imply that the underlying component is vendored from cloudposse-terraform-components/aws-eks-argocd: This component is responsible for provisioning Argo CD. anything provided after 
:
would get a specific release, otherwise get latest
e
it's an interesting convention. We're talking about adding 
metadata.source
I need to reconcile in my head the above; as a user I like it. In atmos, right now, 
import
is for stack configurations (that contain components).
Maybe a component could then provide it's baseline component stack configuration as well?
j
Right, but imagine if 
atmos import
could automatically pull external sources
or make the concept of 
atmos vendor pull
run automatically if the component doesn't exist on the local filesystem
e
Copy code
import:
  - name: vpc/1
    source: <terraform://cloudposse/aws-vpc//src@v1.2.3>
  - name: vpc/2: 
    source: <terraform://cloudposse/aws-vpc//src@v1.2.4>

components:
  terraform:
    vpc/1:
      vars:
        something: true
j
I think we're aligned with our thinking. I'm guessing 
terraform://
implies use of terraform registry?
e
our current plan is the following:
Copy code
components:
  terraform:
    vpc/1:
      metadata.source: <https://github.com/cloudposee-terraform-components/aws-vpc//src@v1.2.4>
      vars:
        something: true
j
The only concern is that the would pull unopinionated terraform. The suggestion was to import components that, to some degree, are already opinionated
e
I think it's a big misunderstanding that atmos requires opinionated terraform
many even think it only works with our components
neither of which is true.
we have opinions on how to write terraform, but none of that is required to use atmos.
j
So then perhaps it's confusion on my part. Isn't cloudposse-terraform-components repositories hosting ready made atmos components?
e
they are ready made, but atmos works with any modules or components (as you know), not just these
so is your point to configure a registry for components
so referencing it is easy
like named component registries
Open in Slack
PreviousNext
Powered by