Feat/get configuration action

[minulo]

What this PR does

Add a get-configuration Juju action so operators can inspect the effective haproxy configuration for debugging without shell access to the unit.

• The action returns the applied /etc/haproxy/haproxy.cfg
• Log a warning when the effective configuration matches the default (no proxy backends configured)

Why we need it

The haproxy charm creates configuration based on its haproxy-route, haproxy-route-policy, and haproxy-route-tcp relations, but there is no way to inspect the effective configuration without shell access to the unit. This spec proposes a get-configuration Juju Action that returns the charm’s configuration out to stdout by both reading from disk and calculating the potential resulting configuration based on current relations.

Checklist

• I followed the contributing guide
• I added or updated the documentation (if applicable)
• I updated docs/changelog.md with user-relevant changes
• I added a change artifact for user-relevant changes in docs/release-notes/artifacts. If no change artifact is necessary, I tagged the PR with the label no-release-note.
• I used AI to assist with preparing this PR
• I added or updated tests as needed (unit and integration)

[Thanhphan1147]

second pass, some more comments, I think we're getting there!

[Thanhphan1147]

Looks good, I think there's only the refactoring and grouping of the tests left until we're good to merge

[minulo]

Looks good, I think there's only the refactoring and grouping of the tests left until we're good to merge

Hey @Thanhphan1147, I believe I have already refactored to test_action that combines both Juju action testing and I used parametrize to group the two existing default-config-warning tests into test_default_configuration_warning. I'm not sure what your comment is point towards. Are you perhaps referring to combining the TestsGetProxiedEndpointsAction with my TestGetConfigurationAction class and refactor to be one class that tests all action?

[Thanhphan1147]

@minulo if you look at the unit tests in this repo we don't put them under a test class, since the module should provide sufficient logical grouping already. Can you remove the test class and just keep the tests as isolated methods?

[minulo]

@minulo if you look at the unit tests in this repo we don't put them under a test class, since the module should provide sufficient logical grouping already. Can you remove the test class and just keep the tests as isolated methods?

@Thanhphan1147 I see... I will then turn it to individual functions then. I assumed using a class would have been the correct choice given the tests for the other action, TestGetProxiedEndpointsAction, were constructed as a class when the other unit tests were all functional. I assume that there are some reason for this that I am not aware of.

[Thanhphan1147]

@minulo oh I think the other tests in that file just happen to not follow the convention of the repo for some reason 😄 We'll have to fix that too.

[Thanhphan1147]

Good to merge once the tests are refactored

[minulo]

@minulo oh I think the other tests in that file just happen to not follow the convention of the repo for some reason 😄 We'll have to fix that too.

Cool, I can handle it in different PR, probably next sprint if you want.