 Good morning. Well, my name is Pepe Amengual. I go by Pepe. My real name is Jose, but that's not getting to details. So I will talk a little bit about how I came here, kind of like my history. I'm a principal in Islam. I'm a consulting company. I got involved with DevOps. You know, when dialogue networking was a thing. So you can now know how I am. If you get close to me, you know, there's a lot of white hair. So, and so I have been around for a while. I've been doing DevOps forever before the term was coined, you know, or SRE because that's how I always worked helping developers and so on. And I got involved with Atlantis about three years ago when I was kind of upset to for because I needed one feature. You don't know anything about Golang. And I decided to just learn Golang and put my first PR and I made too much noise. So I ended up getting invited as a maintainer. So that's how I end up involved in the project. And then by indirect approach, I talked to Dylan and Dylan ended up being one of the maintainers. And now we actually maintain and we are we we got the basically the ownership of the of the project after Luke and Mishra basically donated the project to us. So so now we are the core maintenance of that. So that's a little bit about me. And this is Dylan. Hello, everyone. I'm Dylan. I'm a senior DevOps engineer at Lambda. Previously, I've worked at Digital Ocean and Autodesk. When Pepe asked me to join Atlantis, it was pretty much a no brainer. You know, Atlantis is very much a project when it comes to, you know, when you're working at scale. A lot of times your you and your team are doing terraform or open tofu in this case now runs locally from your laptop trying to deploy infrastructure very quickly and, you know, it becomes very difficult to coordinate. Okay. Hey, I applied this way. Why does my apply say this on what's this doing here? So, you know, you really get a lot of stuff for free when you have a central orchestration system that is able to kind of keep track of everything and keep a history of who ran what why and when. So one question I have to ask, obviously, is that how many people here actually are using Atlantis this day? Okay. If you have complaints, I'm not going to be around. So, you know, and you could you could potentially ask me for something, but we could review PRs, maybe it depends how many beers we have. I don't know, but it has been around for a while. So 2005 or eight 2015. Yeah. Okay. 2015. I used to work half block away from Luke and Misra when they created Atlantis for a food suite. I don't know if you heard about food suite. So I used to be maybe actually eat with him in the same restaurant. I didn't know he actually created the project that I at some point I was going to end up being my maintainers. Pretty, pretty well right. And so for those of you that do not know what Atlantis does is basically I would say maybe one of the first gate ops interactions with terraformed for you to run workflows within your VCS right So now Atlantis supports basically for actually this five VCS so we support ADO, GitHub, GitHub, Bitbucket and Dylan actually merge GTI support yesterday. So now we support GTI. And most of these contributions are the community base. A lot of them. The project was based on GitHub. So there is a tons of support on GitHub obviously so it's a lot of the features we have are mostly GitHub related. That's how we got into the project. I needed GitHub groups for allow for different commands. So that's that's and we were used. We use GitHub. More support than others were different VCS is obviously depending on how many users we have but but we have users that do, you know, for example, one PR a day and some users that do actually 500 PR a day, which is crazy. And since then we the project hasn't changed much. So right now the, I will get into those details a little bit later but basically what Atlantis does and Atlantis is is is an orchestrator for for you to run your telephone workflows or any type of workflow. We are trying to be agnostic. So you can there's people running at most from Cloud Posse, which I used to work in Posse before. So they run CDK, TF, or they run telegram. So my time support around from a long time and open to obviously so and all that can be done through, you know, custom workshops that I will get into details later. Atlantis is a self hosted app. So basically is a binary that you can that we distribute as containers. We have help charts so you can actually deploy it up using the health chance in your Kubernetes cluster or in a container ECS or any other cloud provider. So this is for the web hooks, basically, and then interacts with you through the PR. So the idea is that, you know, the developer never leaves the VCS interface they have. It's kind of annoying when you have to click yet another thing to go to a UI that might not give you all the information. But if it's all in the PR, a lot of people like to see it all in the PR interact there and and and that's why it has so much track and people use it. And basically you what you do is that you interact through commands. So you create your PR Atlantis might do out of discovery. And then it will say it will give you a plan and then you will create a command like here you can do Atlantis apply and it will basically run at her from apply and then, you know, deploy infrastructure. So this is kind of how it looks like. And you guys can see that that's big enough. Basically, in this case, for example, is a very simple new resource project, you know, one one liner basically three lines. And then Atlantis went and did the auto discovery and run the plan output. And this is how it looks like in your PR. So there is a comment from Atlantis bot, which you can call it whatever. And then basically you can see the plan there was going to do and then we can apply a certain logic of rules or behaviors depending of, you know, your your business logic that you need to have for it for someone to be able to apply maybe there's a few people that can apply it or maybe there is rules that can be that needs to be done or you are going to run, I don't know, infra cost to get the cost before it is applied, whatever it is. And you can you can customize it and then basically get an approval. You run Atlantis apply and then that's it. You're basically it deletes the if you want to. You can delete your your source branch and then basically main becomes the source of truth of your infrastructure. We have certain components. So we have by default, if you set up Atlantis, you, you have, you don't really have to set up any of the of these files if you don't if you want to customize it. And if you run a simple PR, it will actually try to auto discover the different files and then it will try to run a plan and then we'll give you the output right away. And then from there, you basically start customizing. Most people obviously customize it. And so we have the repo YAML server side config, which basically it is the the file and mostly the managers of Atlantis deployment will configure for people then to use it for your developers to use it. So for here, you, you have kind of like the, the entry point for the repos to be to be parsed through that rejects where it says their ID. And then from there, you will put all your rules. So we have, we support post and pre workflows that you can run so you can actually auto create some of the files or inject files within your workflow or your PR. That maybe are not part of the PR because they come from dynamic environments or dynamic creation of files or tariff from files, whatever this and you put all the rules that you want for, for the repos to follow within this file. So for example, you can create the workflows that you want to run. For example, let's say that you need to run a specific script before you do tariff a minute. Well, you can set it up here and then every, every, every repo will actually incorporate automatically basically. And then we have the repo side config. So within that, that server side config I was showing you before, basically you can say, Hey, these are the workflows available for you and you cannot modify them, you just have to use this. And then over here, you basically can create your projects, set up which directories are, you know, for example, you can have a prod or, you know, dev or stage directory. And then you will, you will maybe have different versions of terraform and so on. These are some of them. The file was so long because we support so many customizable options. So I'm showing you just a little bit of that file. And, but basically when if you, if you can actually basically say to the user, well, you can use only this custom workflows or you can be more open and say, Well, you know what, you can actually customize the workflows in the repo side. So you have the two options. You can do it on the server side. So some of the options are actually trespassable between the two files, which makes a lot of for opens up for flexibility. And I'm going to actually going to talk a little bit about that flexibility part. But basically these are some of the, the, the, the supported options that we have for people that want to use it. That is a different way. So maybe a team will use it in a different way. And you will want to customize this file and give the, the, your, your teams the option to do so. And the other thing I said, I can, Atlantis can do basically you can run, like I said before pre workflows and post workflows. For example, a post workflow will be a very easy one. Actually, post workflows were created by Infra cost. They actually created the PR and we, we merchant in Atlantis. So thanks to them for, for that. And basically post workflows are everything that you will run after, you know, the plan is done. So maybe you want to run, I don't know, TFSEC or, or you want to run comps test or any other tool that you want to run against the plan, you can run it at that point. And pre workflows are everything that happens before even the plan runs before actually Atlantis tries to run a plan. So for example, you can create dynamically that Atlantis repo YAML because you actually don't know know how many, how many projects within the repo are. So you create the PR and, and if the, if the Atlantis in the repo is not out, is not up to date, it might not actually figured out there is a new directory. So you can actually out to generate it before actually it gets the project gets discovered. So it gives you a lot of flexibility and then you can inject other parameters that you might need to inject for the workflows and so on. And through using pre workflows. So the other thing that we can, you can do, you can run, we have a plugin for comps test, so you can run policy checks. So you can create real rules and run all the rules against the your terraform if you want to unfail those and you can, like I said before, you can generate or inject files that may not be part of the commits for that repo, but they need to be generated in order for your workflows to run. So you can, you can do that in pre workflows. And we have an API now. So, well, now a few years ago and is getting better. But now you basically can run, there's people actually running this using the API to run drift education. So now you can create a PR that will run against all your projects or your workflows. And then it will, if it finds a drift, it then it creates a new PR because Atlanta is based on PRs. So you need to have a PR to actually, you know, interact with your workflow. And now we have actually more commands before we should have plan and apply and help and, well, and version. Now we have a state a state RM import and unlock right now. So yeah, so that's, that's kind of like what that can do. If you want to get started, those are some of the links just go to the website that's run Atlantis that I owe. We have a test drive that you can basically run locally against your, you know, free github or github or whatever account. And you can run it locally and try Atlantis running your local. And we have the latest version, 27 to image and the help charts. So I'm going to go a bit more details about, you know, the history of the project, what current roadmap, how we're working to support open tofu. Some of the stuff we Pepe already touched on so I will kind of breeze through it. But one of the things I really want to call out is right now Atlantis is currently in the process of applying to the CNCF as a sandbox project. Originally, the project was created by Luke when he worked at Hootsuite, and then he joined Hashi Corp. So for a while, there was a lot of gray area about what could we do with the project, what we were allowed to do. And after some discussion, especially after the open tofu manifesto, we were able to get Luke and Hashi Corp to allow us to essentially donate the project to the CNCF. So that was a big, big deal for us. And we're hoping that this April when the committee meets for sandbox applications, we will get approved. So please, there's a link in there for the application. Go thumbs up. We would greatly appreciate it. So big goals for the project that we have. There's been a big focus lately on trying to make the application stateless instead of stateful. Right now it's binary. A lot of the, it runs by default internally internally with the BoltDB. There's been, you know, features to try and kind of break that up. A lot of people either run Atlantis and Kubernetes or they run it separately in AWS Fargate. But there's a lot of scaling considerations when you go, you know, using Atlantis with maybe one repo and you have a couple engineers. It works great. But when you start getting to the scale of some of these companies where they have hundreds of repos with thousands of engineers, it quickly becomes difficult to vertically scale the application. So we're really working to kind of break this apart into a stateless application. There's been features for supporting external DB like Redis. And basically we want to try and move the project towards more of an API driven platform where right now originally the project was very much you have to interact with the user interface of your version control provider. And with the addition of API endpoints to be able to run plan and applies against a repo with a pull request, it kind of opens up to the possibilities of different types of automation and the flexibility of the project to be able to support different use cases. One of the two things I want to really call out is, you know, the get to support. We merged that over the weekend. That's really a big deal. It's really kind of pushes our mantra of supporting open source, not only for the project itself, but for other projects. And, you know, the ongoing work that's being done to support open tofu within the project as well. Some of the big challenges with the project is one is just governance. I spent the last six months, I think, you know, organizing meetings, you know, creating documentation. You know, when you work with an open source project, you don't really think about, you know, just the code. There's a lot that goes into trying to steer a project, trying to organize, you know, and coordinate people around, hey, this is the goals. This is what the project is trying to achieve. And so I'm happy to say, you know, we finally have a governance doc. Part of our application to CNCF is to kind of re rebirth the project in a way that, you know, follows open source and CNCF, you know, standards so that it makes it easier not only for users to support and have faith in the project, but companies as well. One of the big things I like to call it as well is, you know, I have between me and Pepe, we've changed the release process for Atlantis. Previously it was just, you know, we were, you know, spotting off releases here's patch release. It was all off of Maine and it was very, very difficult to bug fix because you'd write a patch release off of Maine and it would include a feature that someone wrote two weeks ago. And then that broke something else. And so we've changed it. So now that there's minor release branches as trunk based deployment where every time there's a release, minor release, we cut off a branch and all patches come, you know, stay on that branch. So there's no possibility of a new feature sneaking into a patch release. Another thing is that the project is very much contributor heavy. The code base, it has a lot of features. A lot of people have, you know, over the years done PRs to support their use case their features and we're happy to do so. But that leaves a lot of technical debt within the code because someone that wrote some feature to do a specific thing two years ago is no longer around and no one has any idea what the heck that feature does or, you know, and if you change something else, well, now that feature is broken, well, no one knows how to fix it. And so it can be very difficult to try and maintain that code. And then the way the VCS providers are maintained, they are maintained within the code binary itself. It's very difficult to do integration testing because I can tell you right now I only really use GitHub. If someone comes to me and says, hey, you know, I have a problem with my GitLab instance and running Atlantis, I'm kind of scratching my head a little bit because I'm like, and so it, the majority of the bugs with Atlantis are usually the VCS provider specific. And it's very difficult to try and support that as well in trying to hunt that down. So because a lot of our user base is GitHub favored. So that's one of the challenges. Specifically with Open Tofu, we have been making progress to try and remove a lot of references to Terraform. This project was really, you know, originally created around Terraform. So there's a lot of hard coded references to the binary in the code base. So there's a lot of a lot of work being done to try and find those and try and kind of remove those and abstract them out. We're also working to add Open Tofu to our container build process so that it ships with Open Tofu and that we add support to auto download the Open Tofu binary like Atlantis does for Terraform if you don't currently have it installed. Right now you can use Open Tofu with Atlantis, but you will need to use the custom workflow process. Essentially you can override the commands that are run during plan and apply to use a different binary and you would just specify Tofu instead of Terraform in this case. This is the same workflow that people use for Terragrunt. So we're working to get that documentation added so it's clear for people who want to use Tofu while we work on official support. And then of course I added the issue epic for Open Tofu if people want to follow along. Project roadmap. So obviously we're not 1.0. I think there's a, you know, a lot of projects tend to follow the only minor releases while I promise we will cut major release. We're not going to go be up to 0.50. But there's some of the things that need to be done before we get then is we need to clean up and remove some of the configuration flags that are deprecated. There's some remaining code QL quality issues that we need to address. There is a longstanding regression with file locking when it comes to running parallel plans and applies. That's something we have been actively tracking with some proposals and to make sure that we address it properly. You know, the new release process which is already done and of course Open Tofu support. But for future releases long term we're planning to try and decouple the VCS providers and do a plugin based architecture to try and kind of spin off essentially Atlantis core from the providers and moving more towards a plugin based system that it will allow people to essentially support or add support for different, different abstractions without having to have to come to the Atlantis maintainers and get our approval. Like I said before, we're trying to be more cloud native that include, you know, multi-survey HDA right now. Atlantis is a single binary and most likely will stay a single binary, but we'll probably the current discussion around that is that we'll probably have different flags for how the binary run, whether it's a, you know, server role or worker role. Some groundwork is already done there with external data stores with whether you are storing the state in externally in Redis or the internal BoltDB. And then of course the important one, vendor neutrality. Currently the Docker image ships with Terraform and Conf test already in there. And one of the big things that I've been trying to push with the project is that we shouldn't really be biased towards what tool or provider or IAC infrastructure is cold tool that you want to use. You know, what Atlantis does well is that it's an orchestrator around your version control and your pull requests. And you should be able to, it kind of highlights with our work with open tofu that, you know, a lot of the stuff is hard coded and that shouldn't be hard quoted in the project. And some of that comes up with some of the recent features with policy tooling with contest and, you know, the different types of policy tools that are out there. And so we want to make sure that we're not alienating or, you know, throwing inherent bias towards a specific tool versus another. So that's one of the, one of the things we want to be conscious towards. And that's about it. Thank you for coming. And if you have any questions, feel free. Do we have time for questions? Okay, go ahead. Oh, that's a that's that before our time question. Definitely before me. So, yeah, I actually don't know. We don't know the reason why I think it was the coolest next name that look found in the Internet at that time before AI. So it's a proper, you know, created name. So, but actually, you don't know. Actually, funny enough that we had a, at some point we have left trying to integrate with us. And they want to create a new version of Atlantis 1.0 with worker using temporal and they were going to call it Nautilus. So to continue the, you know, the trend, but we do not know where that name comes from. Any other questions? Yeah. So that's probably the. Yeah. Oh, yeah. So the question was around. There's the scaling issue with Atlantis, you know, when you have people that are open, you are open up PRs and they are in quick succession of each other. There seems to be a locking issue with Atlantis and how do we how have we addressed it or, you know, do we have any suggestions for improving that? That's one of the things I called out in the slides specifically the file locking. It's definitely something that we're well aware of. It's probably the most the highest priority issue right now because you're not the only one that has reported it. You're not the only one that has seen it. It has to do essentially, you know, there's unfortunately not really a great way around it right now. The best way to address that is it has to do with how it actually is holding the lock. Right now, Atlantis locks on the repo name, the PR number, and then the workspace that is currently in. And a lot of people, especially if they run Terra grunt deployments, they don't use utilize Terra from workspaces. So everything runs within the default workspace. And what happens is because of that, if you have multiple people working in the same PR or trying to or you have multiple projects within the same PR. Those lock up and you don't get that parallel plan and apply going because it is holding a lock for that first project on the repo name and the PR number because it's all being run in the same workspace. So that's being, you know, we have a proposal out for it right now. I don't remember the get issue number, but I linked it in the slides slides will be posted on the. I'll make sure the slides get posted. But it's a, you know, we're following a new proposal format when you know the architecture decision reviews ADR. So it's ADR number two, of course, the first one being that we're going to use ADRs for proposals. The, but it is if there is a deep dive with that issue, there's a pull request out for it where we're trying to address different proposals of how to fix that actual locking. And it probably will have to do with adding more cardinality around what exactly are we locking on. One of the issues that just recently came up has to do with project names. The state that Elanches holds on to doesn't really track project names right now. And we've been working to fix that. And previously with there has been attempts to address the locking by using the path of the project, but that encountered issues and I think even Pepe had to revert some things with that. And so going forward, we'll probably have to once the project name has support within the backing database. We will probably use that to as an additional cardinality for file locking to know this project is currently has a lockout and it doesn't impact the other projects. So you get proper parallelization when you're doing those plan implies in a single PR. Now to add to that, there is companies that I've run, I mentioned companies that they run 500 PRs or so a day or they actually do not use AutoPlan. So that's one big thing that people love about Atlantis, but actually when you get to that scale, you don't want Atlantis just to create a lock file on the plan. I think that there is a PR or we merged it, I can recall where because right now I tend to support disabled the locking so you can disable the lock on Atlantis. But now then you trust on the telephone block no against your remote state. So it all depends at the end of the day and the being right now for for how Atlantis works right now is a matter of communications. If you if I actually never had this problem much before, even in medium sized teams because we disabled out to out to plan. And then, you know, I will create, I will run my Atlantis command, you know, Atlantis plan and maybe I have a project name project Pepe. And then, oh, I got a lot of why, why, why I'm getting a lot of and then I will talk to that person. Hey, are you working on this? I didn't know and then we will try to see who who goes first depending on what the issue is and what they want to fix. So there's a lot of coordination, which is a matter of communication. But there is ways around it right now. But it's a bit more, you have to do it more in a manual human, you know, not automated. Are we? Yeah. So the question was, what are we doing to address some of the technical debt or maybe possibly deprecating features? It's something that we it's a great question. We haven't done yet. We definitely should and plan to it is it's it's hard to kind of, you know, juggle that with, you know, because the part of the project is understanding your users and your code base and who's using what. So you don't want to essentially go through and deprecate something and then have to, you know, kind of walk it back because, you know, people, you know, people weren't interacting with the community. And then you deprecate a feature and then they come out of the woodwork and say, hey, I know I was using that. What are you doing? So it's, you know, that's part of, you know, kind of what how I'm learning to be a maintainer with an open source project. That's one of the things you don't really think about, you know, next to governance and, you know, you know, technically technical steering. But that is a great question. And that's something that we definitely probably should address going forward. I mean, to add to that a little bit, we do actually spend a lot of time looking on regressions. If there is any regressions or, or new features, because we have seen regressions before people, you know, creating a PR like, like Dylan was saying that it would work for for their to solve their problem, but then it could break something else. So we actually spend a lot of time and that's why now if you notice the releases are less often because because we want to take the time to actually look into we have more core maintainers. If you want to be a maintainer for a person's project, talk to us. And because we need more help. I mean, without, without, I mean, we have regular jobs and we do I do this in the weekend for the last three years. And so it actually is, you know, it's hard to with all the work that you do plus actually, you know, look for every PR which I actually do in my that that's my mornings. Look at Atlantis we are, it's still things can go through and then you realize, oh, okay, we brought this thing in GitLab right now. So over, I think in the future, we, you are going to see more ADRs coming in to like, for example, talk about what is the status? What is a VCS status? How we define a status? What is actually a properly applied status or a properly planned status and how that would change in the VCS and so on. And then that the coupling that Dylan was talking will help us to actually have less of that code. And so yeah, so that's part of the answer, I guess. So the question was, what was our philosophy on parity between the VCS is, you know, I can't speak for Pepe, but I think we're pretty aligned like when it comes to philosophy, we try to support all of them as best as possible. And it can be, it can be difficult to do so if you don't use a specific VCS every day. But just like we just merged the get to support, you know, we are not, you know, if there is, you know, contributions or people that want to support a specific VCS provider, we are not, you know, we come one, come all. We definitely are, you know, trying to support as many as we can. It will be nice that, you know, if get live and get have is there's anyone here from the company to talk to us, it will be really cool that it will be the other way around. You know, for like open source projects where, you know, the VCS is basically contribute to us for to maintain, you know, what is a good status on their system, it will be amazing if that could be a thing because it's actually the biggest pain point we have for integrations. You know, especially for the VCS is that are using really big companies like mine uses big bucket who knows big buckets. And so there's no many big bucket users. And then the problem with that is that, well, then there is less features for be bucket to in Atlantis. So then he lacks behind a really long time. And, you know, one of the problems we have our documentation is not paired with the version that on Atlantis. So some people go into documentation. Oh, I'm going to use this, you know, get have this team thing and maybe working in the bucket. No, it doesn't. Oh, it may be works in good. No, it doesn't. So because we can not keep up with all the changes from the VCS and same with the API changes, you know, we have many regulations on API changes that we have to address in good lab. And usually because there is so many people we get a lot of PRs right away very, very quick, but people see the problems before we can actually fix them. So, yeah, one more question. That's it. That's an excellent question. The question was, how do you deploy Atlantis in Kubernetes without without first deploying Atlantis, which is a classic chicken and egg problem. And the answer that is a lot of people tend to deploy it with, you know, AWS Fargate, or they tend to deploy it by itself standalone. If you're using Atlantis to maintain your Kubernetes clusters. And or in some cases, it depends on, you know, it depends on your environment. I know people that are comfortable deploying Atlantis in Kubernetes because they only use it. They deploy their, you know, their management cluster first, they deploy Atlantis in there manually and then from there they manage the rest of the clusters that they manage with Terraform. So it's really up to you on how you your process for standing up your infrastructure and what comes first and having Atlantis part of your, you know, your management plane. But I know people deploy it, you know, standalone on EC2 or Fargate or, you know, whatever cloud provider they use to deploy. Yeah, and it's similar question is how how you deploy your state for Terraform before and how do you import it is the same is the same problem. And it will depend of your workflow, how you like to create the first PR zero, you know, that we I like to call it that that that that starting blueprint for infrastructure. So some people actually run, create it at the time to deployment and first as a standalone, maybe in the quickest way they can to create to actually start the workflow through PRs. So there is a history of the VR. And then they move to they move that that Wefook to the deployment on Kubernetes after the Kubernetes cluster is up and running. So that's another way you can because you can actually deploy Atlantis with Atlantis. So if you want to do it through Terraform and and create a PR against it. So, yeah. Thank you very much. Thank you.