This message was deleted.
# atlantis-community
s
This message was deleted.
p
two Atlantis servers?
w
Yes, one in each env. Security doesn't allow for 1 atlantis server to have permissions to modify everything.
p
ok, do you have the silence-no-project and the Atlantis-exec name settings added?
w
Had to check, we have
Copy code
hide-prev-plan-comments: true
#hide-unchanged-plan-comments: true
quiet-policy-checks: true
p
same repos too?
w
Yes, they both target the same repo in this case. Legacy issue.
p
then you need to change the atlantis config because both apps respond to the same events
all those options where added to be able to run multiple atlantis servers in one repo
w
Ok, the way we currently have it is that this repo "foo", currently has an atlantis-prod.yaml and an atlantis-test.yaml. The atlnatis-prod instance uses the atlantis-prod.yaml and the atlantis instance builds for atlantis.yaml. At present, I don't think we have an issue with the plan, it's where 1 can apply and close the PR even if the other has checks still waiting.
We did review those, and maybe we are misunderstanding how they can be applied in our situation.
p
you need to tell the atlantis servers to only care about the projects configured on their own atlantis.yaml files
and to ignore all other projects
because all VCSs events will hit both servers, with valid payloads and both are going to parse the payload and pull the repo
so they can both respond
if you have separated them by using vcs-status-name etc you can basically instruct each atlantis server to ignore the projects and then no status is changed
👀 1
it says it right there
and
w
OK, I previously posed the setting for the test atlantis instance. From looking at the prod instance we have the following configured
Copy code
silence-vcs-status-no-plans: true
silence-no-projects: true
hide-prev-plan-comments: true
#hide-unchanged-plan-comments: true
quiet-policy-checks: true
parallel-pool-size: 50
vcs-status-name: atlantis-prod
executable-name: atlantis-prod
p
the test instance should look the same but
-test
w
So assuming that the test instance was as you describe, what's the workflow. So we have a 1. A PR is opened for a project in the test env. 2. Both Atlantis servers will be notified via webhook. 3. The prod instance will see that the project is not in it's configured atlantis-prod.yaml and do nothing. 4. The test instance will see that it does need to run a build and will post the plan results back to the PR under the name
atlantis-test
. 5. A user will then approve PR and comment
atlantis-test apply
and the PR will be applied and closed. Is the above the correct flow of events for the single project case?
p
yes
basically one server will always ignore
which version of atlantis?
w
OK, great. Here is where we think things are breaking down. 1. A PR is opened for a project in the test env and a project in prod. 2. Both Atlantis servers will be notified via webhook. 3. The prod instance will see that it needs to plan a project in the PR and will do so, resulting in PR comments under the
atlantis-prod
name. 4. The test instance will see that it too needs to plan a project and will post the plan results back to the PR under the name
atlantis-test
. 5. A user will then approve PR and comment
atlantis-test apply
and the PR will be applied and closed. 6. The prod project was never applied.
Let me check on the version.
v0.23.3
p
you will need to configure the test atlantis to not merge the PR
because at the end the
"promotion"
to prod is what actually validates the code so in a way the prod deploy should merge the PR since is the
source of truth
I think maybe there is a limitation on the locks here too because the repo should be locked for the prod server when there is a PR in flight
but the Lock is not shared so the prod server does not know about it
and actually you could be applying an already tested code that you deploy to test but now you are promoting to prod, so the PR in test is ahead and doing something else but prod is applying behind test
interesting
I’m trying to think if I ever run into this problem before when I had two servers
w
It's really like we need the 2 servers to ask each other if it's OK I merge this PR. Prod says I'm not doing anything we that PR, so go ahead. Or whoa, I have an open plan on that guy, hold off.
p
and that is really hard