https://cloudposse.com logo
Join Slack
Powered by
<@UB2EH889X> do you guys have an example of a "mat...
# atmos
z
@Erik Osterman (Cloud Posse) do you guys have an example of a "mature" atmos repo publicly? We're just starting to run into versioning issues.. re-structing of our 
vendor.yaml
(renovate bit us) etc and looking at how to implement properly with 
abstract
includes
Was reading through the versioning best practices documentation but it would personally help me a lot to be able to go stare at a repo
extra context: We have a mono repo, with a bunch of different stacks in it, using the same 
vendor.yaml
, mixins, imported components etc. We are not currently versioning our "targets" ex
Copy code
vendor.yaml
apiVersion: atmos/v1
kind: AtmosVendorConfig
metadata:
  name: example-vendor-config
  description: Atmos vendoring manifest
spec:
  # `imports` or `sources` (or both) must be defined in a vendoring manifest
  imports: []

  sources:
    # `source` supports the following protocols: local paths (absolute and relative), OCI (<https://opencontainers.org>),
    # Git, Mercurial, HTTP, HTTPS, Amazon S3, Google GCP,
    # and all URL and archive formats as described in <https://github.com/hashicorp/go-getter>.
    # In 'source', Golang templates are supported  <https://pkg.go.dev/text/template>.
    # If 'version' is provided, '{{.Version}}' will be replaced with the 'version' value before pulling the files from 'source'.
    - component: "vpc"
      source: "github.com/cloudposse/terraform-aws-components.git//modules/vpc?ref={{.Version}}"
      version: "1.398.0"
      targets:
        - "components/terraform/vpc"
say we update the one 
vendor.yaml
for vpc to 
2.0.0
, and there's breaking changes ( need new input variables or whatever ) since the target directory isn't versioned, we need to update the variables everywhere at the same time that uses this component (like ~60 stacks)
other thing is that we are currently gitignoring our 
./components/terraform
directory
There's not a sane way to have multiple 
vendor.yaml
files, right?
e
For version management we've published extensive documentation on how to think about it
Also, we are working torward "Just in time" vendoring maybe by the end of year or early January.
There's not a sane way to have multiple 
vendor.yaml
files, right?
Vendoring supports 
import
šŸ‘€ 1
do you guys have an example of a "mature" atmos repo publicly?
We don't - this is actually what we sell with our "Quickstart" and "Jumpstart" packages.
It's the only thing we withhold.
šŸ‘ 1
z
Interesting - imported vendoring with stack level vars to determine versions šŸ¤”
not sure if that's a thing
e
No, I'm referring to vendor manifests which support the 
import
keyword
Not stack manifests that also support the import keyword
Stack manifests cannot import a vendor manifest.
Stack-level variables cannot be used in vendor manifests because vendor manifests are not stack aware
We are planning to add the following to stack manifests:
Copy code
components:
  terraform:
    something:
      metadata:
        source: https://..some..vendor..url/
        workdir: true
Which will vendor that source "just in time" automatically
would that help?
z
Yeah that should - basically the versioning would be able to be managed at the component level
Is it going to be possible variablize? i.e.
Copy code
vars:
  module_versions:
    vpc: 1.2.3

components:
  terraform:
    something:
      metadata:
        source: "https://..some..vendor..url/?ref={{ .vars.module_versions.vpc }}"
        workdir: true
āœ… 1
e
yes, that will be fully supported
Once PR #1813 merges (large refactor of terraform handling), we're going to start implementing the following, which shouldn't be too hard. ā€¢ Just in time vendoring (single source per component) ā€¢ Provider cache management ā€¢ File generation
z
Provider cache management would be nice. We have been seeing random timeouts during our workflow applies lately for terraform providers when it's running the init
Thanks for the info - yeah I'm not sure how my team is going to want to handle this. We lean towards pinning everything and using releases
e
yeah I'm not sure how my team is going to want to handle this
Meaning before the 
metadata.source
feature or after
z
> Meaning before the 
metadata.source
feature or after I think once metadata.source is introduced, we would probably lean towards the just-in-time vendoring There's just many ways to handle this and conceptualize solutions. Today I've been going down the rabbit hole of importing stack level vendor.yaml files, and using tags to define what stack should pull what, but with that we'd need to move tags around to promote what stack is using what and potentially think in terms of like different release tracks - stable, latest.. etc Apparently there's a 
atmos vendor pull --stack
stack switch that doesn't work yet unfortunately, guessing that's related to the JIT feature
e
Apparently there's a 
atmos vendor pull --stack
stack switch that doesn't work yet unfortunately, guessing that's related to the JIT feature (edited)
that might be a regression
3 Views
Open in Slack
PreviousNext
Powered by