Atlantis 1.0.0 Release

[nitrocode]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request. Searching for pre-existing feature requests helps us consolidate datapoints for identical requirements into a single place, thank you!
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

---

• I'd be willing to implement this feature (contributing guide)

Describe the user story

It would be nice to legitimize Atlantis for production by putting together a list of necessary items to create a 1.0 release.

This was also mentioned in the Atlantis slack community on Aug 9 2021 by @nishkrishnan

Atlantis was initially intended to be interfaced solely through PR actions due to a number of reasons such as:

• Getting persistence for free with Github PRs.
• Getting an audit trail for free with PR search/history
• The benefits of markdown templating in comments
• Ease of project bootstrapping

However, as Atlantis is more widely adopted by the community we want to provide some direction for the project and hopefully expand the capabilities of the platform. Atlantis 1.0 is the goal we are setting for ourselves to move towards an API driven platform that’s integrated with version control but NOT entirely dependent on it. This provides the building blocks for things like integrating with other services (ie. deploy pipelines), enables usage of a standard release process (ie. post-merge to default branch) and ultimately allows us to build a richer experience since we’re not limited by VCS provider functionality (ie. real-time feedback and better formatting).

This is a large endeavor and we don’t expect to release 1.0 until we are confidant that the platform is stable. As for how we intend to do this, we plan on tackling this incrementally through a couple projects in the short-term that will bring us closer to this vision:

• Real-time feedback/streaming of terraform outputs
• Supporting multiple entrypoints into the system (events and api)
• Decoupling VCS specific logic from the core components of the platform
  What can the community do to help?

Keep this vision in mind when contributing features/bug fixes as we want to make sure we are moving forwards not backwards. In addition to that stay tuned for more technical specifics on the next steps.

Describe the solution you'd like

Come up with a list of items that need to be complete for a 1.0 release

• Real-time feedback/streaming of terraform outputs
  • This may already be completed since websockets for workflows were implemented
  • feat: streaming terraform logs in real-time #1937
• Supporting multiple entrypoints into the system (events and api)
  • This may already be completed since /plan and /apply routes were implemented
  • Add the /plan and /apply endpoints #997
• Cloud agnostic
  • proven to work on aws, gce
  • aws - https://github.com/terraform-aws-modules/terraform-aws-atlantis
  • gce - https://registry.terraform.io/modules/bschaatsbergen/atlantis/gce/latest
  • k8s deployment via helm chart - https://github.com/runatlantis/helm-charts
• Add debian docker image flavor
  • Completed by feat: Separate docker image types in matrix, add debian #2770
• Deprecation of old flags
  • Deprecate old flags #2992
• CodeQL issues
  • Resolve CodeQL issues #2884

Future release

• Decoupling VCS specific logic from the core components of the platform
  • This could be completed using go modules and a separate repo per vcs
  • Split VCS using a plugin based architecture #2991

Describe the drawbacks of your solution

None that I can think of

Describe alternatives you've considered

None

[jamengual]

I think atlantis has been in production for years, I believe the 1.0.0 release is just a number, not an actual representation of where atlantis is.

What do you think is missing?

[stasostrovskyi]

As mentioned in Slack, I personally think that making atlantis, hmm, cloud-native would be a such missing thing for version 1.0.
By cloud-native here I mean having a separate repository and plan storage, and locking db (which is already implemented) so that Atlantis can be horizontally scaled in Kubernetes or otherwise usable with Google Cloud Run or similar tools from other cloud providers.

[jamengual]

locking db as you mentioned was merged yesterday and that will enable autoscaling.
the next nonissue but improvement is to maybe use the locking table to find out IF there is already a lock/clone of the repo get the location and use it from shared storage instead of doing a clone again BUT even without that Atlantis will do what is supposed to.

I guess I'm trying to understand what cloud-native means?, because Atlantis needs to be cloud provider agnostic BUT that does not mean that they could be an implementation that uses S3/blob storage to save the clones etc.

I think we will hear back soon from people using the external locking and enabling things like EFS for the AtlantiData dir and we will see how that behaves, my guess is that it might work just fine.

[stasostrovskyi]

Oh, I missed the part that it's possible to use EFS or similar. We will try it with google filestore and see how it works!

[snorlaX-sleeps]

For a v1 release Atlantis should be able to run parallel plans for different workspaces that are in separate directories.
This was previously tested / deployed in a nightly build via this PR but was pulled due to an issue with Terragrunt (not 100%) on the reasoning.
We are still using this several month old nightly build as we have multiple repos containing n directories, each with between 1 and 7 workspaces and not having these run in parallel makes Atlantis unusable as part of the developer workflow (takes far too long)

[snorlaX-sleeps]

enabling things like EFS for the AtlantiData dir

@jamengual - we attempted to use EFS in AWS but it was far too slow. EFS is not very good at handling lots of small file reads / writes (e.g terraform init)

[jamengual]

you need to test in the next tier of EFS: Q. How much throughput can a file system support? Bursting throughput mode, which is the default throughput mode for Amazon EFS file systems, scales the throughput available to a file system as that file system grows. Because file-based workloads are typically spiky - requiring high levels of throughput at certain periods of time and lower levels of throughput otherwise - Amazon EFS is designed to "burst" which allows high throughput levels for periods of time. Also, because many workloads are read-heavy, read operations are metered at a 1:3 ratio to other NFS operations (such as write). All file systems deliver a consistent baseline performance of 50 MB/second per TB of EFS Standard or EFS One Zone storage, while all file systems (regardless of size) can burst to 100 MB/second, and file systems with more than 1 TB of EFS Standard or EFS One Zone storage can burst to 100 MB/second per TB. Since read operations are metered at a 1:3 ratio, you can drive up to 300 MiB/second per TiB of read throughput. As you add data to your file system, the maximum throughput available to the file system scales linearly and automatically with your storage in the Amazon EFS Standard storage class. If you need more throughput than you can achieve with the amount of data you have stored, you can configure Provisioned Throughput to the specific amount your workload requires. https://aws.amazon.com/efs/faq/ create a dummy 1 TB file to jump to the next tier.

…

On Thu, Sep 22, 2022 at 10:49 AM snorlaX-sleeps ***@***.***> wrote: enabling things like EFS for the AtlantiData dir @jamengual <https://github.com/jamengual> - we attempted to use EFS in AWS but it was far too slow. EFS is not very good at handling lots of small file reads / writes (e.g terraform init) — Reply to this email directly, view it on GitHub <#2496 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAQ3ERG2L6BK2VJI4CAW64DV7SLZ3ANCNFSM6AAAAAAQGGHRHQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[snorlaX-sleeps]

create a dummy 1 TB file to jump to the next tier.

Could do! But a 50Gb EBS is a fair bit cheaper than a 1TB EFS (or so it was when we were originally deploying Atlantis).
I suppose we could share the EFS across all our installations instead

[pauloconnor]

Off topic from V1.0, but I used EFS with provisioned IOPS of a reasonably high number, and the performance was still garbage. Looking at clones taking 2+ minutes compared to ~10 seconds to an EBS volume. I wonder if it'd be possible to split up the atlantis directory so that the plan files are stored on EBS, and the git check out is stored on ebs or instance storage

For a v1 release Atlantis should be able to run parallel plans for different workspaces that are in separate directories.
This was previously tested / deployed in a nightly build via this #2131 but was pulled due to an issue with Terragrunt (not 100%) on the reasoning.

Curiously, we're using multiple plans in different directories, and it runs quite quickly, excusing EFS issues mentioned above

[snorlaX-sleeps]

Curiously, we're using multiple plans in different directories, and it runs quite quickly, excusing EFS issues mentioned above

@pauloconnor - Yes, it will run plans in parallel in different directories if the workspace names are different.
In my work we use a common format for workspace names across all our products and these are the same in each directory.
Unless something has materially changed (not mentioned in docs / releases last time I checked) it can't run workspaces with the same name in parallel, which is why we are using the old nightly build

[pauloconnor]

Yes, it will run plans in parallel in different directories if the workspace names are different.

We don't use different workspace names - just default. Parallel plan has worked for several months for us. This was the PR that enabled it to work

[snorlaX-sleeps]

Yes, it will run plans in parallel in different directories if the workspace names are different.

We don't use different workspace names - just default. Parallel plan has worked for several months for us. This was the PR that enabled it to work

Apologies @pauloconnor - I realised I linked the wrong PR we were using for the workspaces, it was this: #2180
Updating previous comment for anyone reading this later on.

So yes, different directories can run in parallel, but if they use workspaces with the same name they don't run in parallel
When you use the linked PR, you can have any 16 workspaces planning or applying at the same time

[pauloconnor]

So yes, different directories can run in parallel, but if they use workspaces with the same name they don't run in parallel When you use the linked PR, you can have any 16 workspaces planning or applying at the same time

That's completely different to what I've observed on my Atlantis node - using multiple different directories with the same workspace name which all have changes, each directory will spin up a Terraform process in parallel. I have seen more than 16 concurrent tasks running