Help to make const AtlantisYAMLFilename = "atlantis.yaml" configurable

[georgedriver]

Help to make const AtlantisYAMLFilename = "atlantis.yaml" configurable

Can we add a new Flag to support select atlantis.yaml with a flag like atlantis server --atlantis-yaml-config my_second_atlantis.yaml?

We really need this to support one repo but have two Atlantis backend. Thanks.

[lkysow]

Hi George, I totally get what you're trying to accomplish but I'm not sure if this is the best way to do it. I'd prefer a solution that has a bit more "smarts" because I'm worried that two Atlantis's operating without knowledge of each-other might end up in weird edge cases.

For what it's worth, there's a PR with some commits you could use if you wanted this functionality right now: #310

[pysysops]

Hey @lkysow

I know this is a rather old thread with some older PRs and a few similar issues related to the multi-account / multi-server problem.

I'm keen to help work out what more "smarts" might look like or be and do some work to get nice PRs raised for approval. Im sure there's a few users out there needing something to help them when they're in a situation of using the same codebase but are unable to grant cross account access or have a "management" account (organisational or some other imposed policy).

Do you have any high level ideas on what could be good functionality to aim for?

I'm worried that two Atlantis's operating without knowledge of each-other might end up in weird edge cases.

Do you think there's some sort of case for shared locking or some other mechanism to allow multiple instances to work out what they've done or what they should do?

[jhcolville]

Hey Luke (@lkysow )

First thanks very much for your ongoing amazing work on Atlantis. I apologise for updating this old issue/feature again, but since it was still open I figured it was probably the best place.

I think I can understand your concerns around explicitly supporting multiple Atlantis servers operating on a single repository, but is there any chance you would reconsider a PR like that outlined in #310 along with documented adequate warning that incorrect configuration could result in unpredictable results?

The competing interests as I see them are tricky to fully reconcile:

• consolidated repositories like this are a common pattern, especially with other tools like terragrunt
• the purpose of consolidating repositories like this is to avoid duplication, which breaking the repo down to work 1:1 with an Atlantis server would obviously introduce
• it is probably fairly difficult to implement any meaningful checks and balances to prevent independent conflicting operations on a terraform configuration, outside of those already implemented by terraform itself

I've been keeping a weather eye on this project for a while looking for an opportunity to implement it in our org, at first I was disappointed when I realised that this problem would present itself, then thrilled when I saw others had identified the same use case, then disappointed again when those enhancements had been discounted for whatever reason - it's been a rollercoaster :-)

Thanks,

Johan

[lkysow]

Hey, if you've got bandwidth to take a stab at this then I'm happy to review the PR.

[jhcolville]

@lkysow - thanks for being open to the idea of this feature again.

I'm an amateur in terms of go development experience, but I'll take a look for sure. Before I wade in, @darrylb-github / @osterman - apologies for summoning you from #310 - I can see you've both done some work on this in forks / declined PRs, do you still have a use for this feature? Is dusting off an existing PR an option here?

Even if this feature existed today I'm going to have to make a case for Atlantis in our org - something I do want to do - because my alternative is to try and adapt aspects of it into an AWS Codepipeline / Codebuild framework (we already have quite a bit of those) which is a task I'm not really looking forward to at all. I only point this out to say that I'm not shirking rolling up my sleeves to attempt these adjustments, just that like everyone else I guess time is short and if there are any possible shortcuts I'd definitely welcome them :-)

[darrylb-github]

Hey @jhcolville ,

I ran this in my last org successfully with the code from #310, as we needed that clean separation between staging and production. The main compromise from memory was the extra comments as both atlantis servers would report back on the PR.

Since it didn't get merged however, when setting up terraform and atlantis in a new org, I've just caved in and accepted the 1 super atlantis managing staging and production from it's own infra, but I still feel this isn't ideal.

I don't think I'll ever move away from the consolidated repo approach containing the terraform for multiple environments though, as this is super convenient to work with.

I still don't fully understand what the main problem with the previously suggested approach is though. The two atlantis instances are operating on different directories and projects so I don't think there are any edge cases unless the user misconfigures things which isn't something unique to that approach. And even if they did, terraform already has a lot of smarts to deal with this kind of scenario. It also wouldn't be the default behaviour so most users would never have to deal with it unless they go out of their way to configure it 🤷. I reckon people would still get value from it.

Maybe it could be improved though to try and avoid the empty comments back. E.g. when I'm changing something in staging, the production atlantis instance receives the same webhook and does a no changes comment back. Maybe when running in this mode only it could have some extra smarts to try and avoid those extra comments when it knows more than 1 atlantis is operating on the repo. Not sure if this could be done cleanly, but if this was solved then it would be a fairly clean approach to the whole problem in my mind.

[jhcolville]

Hi @darrylb-github ,

thanks very much for taking the time to reply in detail - I hadn't banked on the fact that even with this change implemented there would be "no changes" responses from servers with no work to perform... my inexperience with Atlantis showing there I guess. It seems odd that a response would be warranted at all when there are no matching projects with modifications in the atlantis.yaml file, but I guess it makes sense from the perspective that any given server should acknowledge/respond to an "atlantis plan".

Maybe the conditions for the no changes comments can be tweaked or made configurable, for sure though it's a little more involved than having a configurable repo level atlantis.yaml file. I should have guessed it wouldn't be so straightforward :-) I'll have a poke around and keep thinking about it!

Cheers,

[mveitas]

@jhcolville @darrylb-github I'm very much interested in getting this kicked off again and willing to put some time into making this happen. This is something our org has been wanting and we concerned forking Atlantis to support this (not ideal). Let me know how I can help!

[nitrocode]

This is solved by #2798

https://www.runatlantis.io/docs/server-side-repo-config.html#multiple-atlantis-servers-handle-the-same-repository