feat: expose idle timeout loadbalancer input

[vburckhardt]

Description

Expose https://registry.terraform.io/providers/IBM-Cloud/ibm/latest/docs/resources/is_lb_listener#idle_connection_timeout in the lb inputs.

Part of terraform-ibm-modules/terraform-ibm-landing-zone#609

Release required?

• No release
• Patch release (x.x.X)
• Minor release (x.X.x)
• Major release (X.x.x)

Release notes content

Run the pipeline

If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.

Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:

/run pipeline

Checklist for reviewers

• If relevant, a test for the change is included or updated with this PR.
• If relevant, documentation for the change is included or updated with this PR.

For mergers

• Use a conventional commit message to set the release level. Follow the guidelines.
• Include information that users need to know about the PR in the commit message. The commit message becomes part of the GitHub release notes.
• Use the Squash and merge option.

[vburckhardt]

/run pipeline

[vburckhardt]

/run pipeline

[argeiger]

LGTM

[rajatagarwal-ibm]

I suggest to mention that "idle_connection_timeout" is used only by application load balancer.

[rajatagarwal-ibm]

Also, the unit test failed because of the auth policy conflict. Probably need to delete existing policy manually before re-running the pipeline.

Separate to this task - we probably need to investigate ways to check the auth policy prior to creating it. This will avoid "auth policy conflict" issues. If you agree @vburckhardt I can create a task to look into this.

[ocofaigh]

The upgrade test failed with this, which seems expected, so I suggest skipping it:

        	Messages:   	Resource(s) identified to be updated Name: listener Address: module.slz_vsi.ibm_is_lb_listener.listener["slz-vsi-com-upg-sjfifs-lb"] Actions: [update]
        	            	DIFF:
        	            	Before: {"idle_connection_timeout":50}
        	            	After: {"idle_connection_timeout":100}

[ocofaigh]

@rajatagarwal-ibm The issue with clashing auth policies is a known issue. It happens because the block storage auth policy cannot be scoped to a specific resource group, and because we use a permanent HPCS instance, so it means such a policy may already exist in our account from a parallel test, or an old test that did not get cleaned up.
The only way to avoid it would be to stop running the fscloud example (which requires HPCS) and instead create an example that uses a Key Protect instance that we create as part of the tests so the auth policy would always be unique for the new instance

[vburckhardt]

/run pipeline

[ocofaigh]

Most of the time this auth policy will not exist actually, and this test will fail. The nuke nukes all global auth policies. We could add a feature to the nuke maybe to pass an ignore list of auth policies? Since policies don't have a name, we can't use the geretain prefix to tell nuke to ignore them - we would have to add a new way to ignore policies.

[ocofaigh]

I actually think this is a good feature to have with the nuke, so I have created an internal issue for it

[vburckhardt]

We need to really review our testing approach here, I am spending 10x the time to get that pipeline to pass on unrelated aspects, than actually coding the change. We have a problem.

[vburckhardt]

I'll comment it out, I think we need to invest in fresh account created for tests that touch account level resources like s2s policies. Once we have an enterprise account, we can create subaccounts for it for each new test run.

[ocofaigh]

FYI, we have the enterprise account already, so we should deep dive on next steps

[vburckhardt]

Let's prioritize this in next sprint.

[vburckhardt]

/run pipeline

[terraform-ibm-modules-ops]

🎉 This PR is included in version 2.13.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀