add scaling threshold to crd

[OliverMKing]

Description

adds scaling threshold to crd to configure how fast hpa scales. The options provided are known good values. We use enums to control the actual values which we scale test internally. We control cpu requests so that is another reason why these are enums.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

locally, e2e, unit

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[coveralls]

Pull Request Test Coverage Report for Build 8361454969

Details

• 23 of 30 (76.67%) changed or added relevant lines in 3 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage decreased (-0.06%) to 80.721%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/controller/nginxingress/nginx_ingress_controller.go	22	24	91.67%
api/v1alpha1/zz_generated.deepcopy.go	0	5	0.0%

Totals
Change from base Build 8361450806:	-0.06%
Covered Lines:	2596
Relevant Lines:	3216

---

💛 - Coveralls

[OliverMKing]

/ok-to-test sha=c956d0f

[OliverMKing]

/ok-to-test sha=1e93c26

[OliverMKing]

/ok-to-test sha=53d11ad

[sabbour]

Approved from naming/description perspective

[jaiveerk]

few changes requested. I know we’ve got fixture tests so our bases should be covered but is there any feasible and useful way we can test for this in e2e to ensure our output values are correct all the way through to hpa deployment?

[OliverMKing]

/ok-to-test sha=2012fa4

[OliverMKing]

few changes requested. I know we’ve got fixture tests so our bases should be covered but is there any feasible and useful way we can test for this in e2e to ensure our output values are correct all the way through to hpa deployment?

not really that useful to check this in e2e. the code for this addition is all pure functions so unit tests do a good job. e2e for this would look like provisioning a crd then checking the backing hpa numbers which is exactly what we do in unit tests.

instead these numbers will be validated at a higher level in scale tests along with the full functionality

[bfoley13]

Changes look good

[OliverMKing]

not really that useful to check this in e2e. the code for this addition is all pure functions so unit tests do a good job. e2e for this would look like provisioning a crd then checking the backing hpa numbers which is exactly what we do in unit tests.

also want to note that we do add e2e tests for the one thing that we can't validate in unit tests which is crd validations (the rejection test ensuring that we can only use one of the enums)

[OliverMKing]

/ok-to-test sha=bcbe73d