https://cloudposse.com logo
Join Slack
Powered by
I’m doing <reference architecture> with `atmos` :...
# geodesic
m
I’m doing reference architecture with 
atmos
cloudposse Vendir sync need to download repos defined in 
vendir.yaml
to put them to components. There are 16 modules using https://github.com/cloudposse/terraform-aws-components I think there are two problems slowing me down: • 
vendir
doesn’t have caching layer for modules using same version • every change to 
vendir.yaml
need to redownload all modules and compare them to components even if nothing has changed (
.vendir-tmp/git
is cleared after every module downloaded) • 
vendir
seems slow… 
real    4m46.736s
I know it’s partially because the repo is quite big but just using git it’s super quick to clone it. 
vendir
lastest 0.17.0 I wonder how it behave with many many modules and upgrades to them. Is there a plan to make it more quick?
e
Using 
vendir
effectively is blocked by https://github.com/vmware-tanzu/carvel-vendir/issues/37
So we're currently not using it until we can get around to opening a PR for this.
Generally, upgrading of root modules (components) is not feasible in a mature environment.
Root modules are the foundation and upgrading them is often a violent operation.
Instead, our root modules (components) point to upstream modules which can be upgraded.
Our (cloudposse) objective using 
vendir
is primarily to accelerate the coldstart process.
also, @Marcin Brański our 
terraform-aws-components
there are already quite out of date. We have new ones. If you reach out to me directly, I can probably get you access to newer ones provided you help us upstream them.
m
Yeah man. I noticed they are outdated so I had to use 
tf13
because of that.
Our (cloudposse) objective using 
vendir
 is primarily to accelerate the coldstart process.
Understand, I thought it’s new pattern where vendir would populate components but it seems we should be putting new modules (manually) to 
components
dir and not execute 
vendir
beside bootstrapping, yeah? Early access to updated modules would be great. What I ran into today is that variables (none of them, context as well) from terraform module are not passed to modules
Copy code
tfstate-backend:
    vars:
      namespace: terraform
      force_destroy: false
      prevent_unencrypted_uploads: true
      enable_server_side_encryption: true
but global vars works… I need to wrap my head around that… So for multiaccount setup it’s recommended multi repo?
e
t it seems we should be putting new modules (manually) to 
components
 dir and not execute 
vendir
 beside bootstrapping, yeah?
Correct
Early access to updated modules would be great.
Yup, shoot me an email and let's discuss. This benefits everyone.
What I ran into today is that variables (none of them, context as well) from terraform module are not passed to modules
Nah, that's probably just a whitespace issue 😃
component vars are 💯 passed to the terraform modules.
So for multiaccount setup it’s recommended multi repo? (
No - we've entirely walked away from this approach. We use a mono repo for infrastructure.
mult-repo is not gitops friendly - it makes coldstarts expensive and difficult to automate
m
I will shoot you an email later today when I will be more familiar with 
atmos
. I need some more time to ask better questions but I love the idea ❤️ My bad with not passing context was that I mixed reference architecture, atmos example and atmos tutorial which resulted in wrong yaml definition. I had:
Copy code
components:
    vpc:
      vars:
        cidr_block: "10.100.0.0/16"
where it should be
Copy code
components:
  terraform:
    vpc:
      vars:
        cidr_block: "10.100.0.0/16"
e
ya, yes, that ref arch is out-of-date and old/misleading
sigh... so many easter eggs! just in time for easter
2 Views
Open in Slack
PreviousNext
Powered by