Remove ca-a and ca-b distinction in test configs #7238
Conversation
|
@pgporada, this PR appears to contain configuration changes. Please ensure that a corresponding deployment ticket has been filed with the new configuration values. |
|
No config changes are necessary. The bot was triggered due to me renaming and removing configs. |
There was a problem hiding this comment.
Nice, thanks for working on this.
We do still want to run two separate boulder-ca instances. We just want them to use a single config file. That means the changes to config.hcl are a little wrong. I'm actually not sure why we have [ca-a,ca-b] in there in addition to [ca1, ca2]. But we want only the latter.
Also, in startservers.py we should still have two stanzas to run boulder-ca instances.
|
I'm certain that we have
The doc description for Name is a bit cryptic for me, but the consul web UI shows me exactly what I expected to see. |
There was a problem hiding this comment.
It looks like https://github.com/letsencrypt/boulder/blob/main/test/consul/README.md doesn't fully spell out the distinction between the "foo-a/b" and "foo1/2" stanzas in the consul config file, so it might be nice to make that documentation more explicit. But that doesn't need to be part of this PR, LGTM as-is.
While working on #7238, I dug into why the consul services config has, for example, `[ca-a, ca-b]` in addition to `[ca1, ca2]`. Boulder test configs use `ca.service.consul` which will return both CAs (`[ca-a, ca-b]`). For `[ca1, ca2]` though, a grpc load balancing [integration test](https://github.com/letsencrypt/boulder/blob/a55bf19ea062febc94b5054a004e447aa5b3a6bd/test/integration-test.py#L121-L143) individually targets services such as to verify that each backend is working correctly.
Fixes #7187