Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix(ecs): adding a circuit breaker causes Service replacement (under feature flag) #22467

Merged
Changes from 1 commit
Commits
Show all changes
23 commits
Select commit Hold shift + click to select a range
8464201
Backwards-compatible implementation with tests
Oct 12, 2022
51e6b37
update integration test
Oct 12, 2022
6c19367
Update packages/@aws-cdk/aws-ecs/lib/base/base-service.ts
fergusdixon Oct 19, 2022
02192e1
create new test
Oct 19, 2022
28801f2
revert old snapshot changes
Oct 19, 2022
21c3859
implement feature flag, some old integration tests failing
Oct 25, 2022
b177682
fix error annotation
Oct 25, 2022
5aa23fb
set old integration tests too old behaviour
Oct 25, 2022
de2cc2a
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
fergusdixon Oct 26, 2022
b2df8de
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
fergusdixon Oct 28, 2022
f8daa6d
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
fergusdixon Oct 31, 2022
975c6de
use feature flags in old integ tests
Oct 31, 2022
d22be52
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
fergusdixon Oct 31, 2022
d2bcfa4
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
fergusdixon Nov 1, 2022
3723d3e
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
fergusdixon Nov 3, 2022
66f2036
remove useExplicitEcsDeploymentController option to only rely on feat…
Nov 3, 2022
0a4a8a0
add snapshot
Nov 3, 2022
552e5e8
remove old snapshot
Nov 3, 2022
deb9800
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
Nov 7, 2022
94117ee
add auto-built readme line
Nov 7, 2022
2f72339
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
Nov 8, 2022
1500b74
rebuild feature flags
Nov 8, 2022
f65b647
Merge branch 'main' into fix/remove-explicit-ecs-deployment-type-for-…
mergify[bot] Nov 9, 2022
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Update packages/@aws-cdk/aws-ecs/lib/base/base-service.ts
Co-authored-by: Jamie Schenker <jam1esch3nk3r@gmail.com>
  • Loading branch information
fergusdixon and xXPOLYGONXx committed Oct 25, 2022

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
commit 6c19367a8fde5dab1c6232a0578343537e81dbe3
2 changes: 1 addition & 1 deletion packages/@aws-cdk/aws-ecs/lib/base/base-service.ts
Original file line number Diff line number Diff line change
@@ -56,7 +56,7 @@ export interface DeploymentCircuitBreaker {

/**
* Whether to use the explicit DeploymentControllerType.ECS when defining the circuit breaker.
* To avoid a service replacement when add a CircuitBreaker to an existing ECS service, set this to False.
* To avoid a service replacement when adding a CircuitBreaker to an existing ECS service, set this to false.
* @default true
*/
readonly useExplicitEcsDeploymentController?: boolean;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@fergusdixon I've been thinking about this and as much as a don't want to introduce a new feature flag I think that's the best thing to do here. We want the new default behavior to be false and a feature flag is the only way to accomplish that.

https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md#feature-flags

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure will give it a bash next week, thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@corymhall I have a working implementation with the flag, however I'm struggling to see this to false in the integration tests specifically. Should the integration tests cover new or old behaviour (I would imagine both), however I cant seem to set the feature flag value the same way as the unit tests do?

Copy link
Contributor Author

@fergusdixon fergusdixon Oct 25, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems the integ-helper sets all feature flags to FUTURE_FLAGS (new behaviour), and this takes precedence over the context prop passed to App in the test. So from this it seems integration tests should test new behaviour and unit tests for both?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want to test the old behavior you can use the postCliContext parameter on App.

Copy link
Contributor Author

@fergusdixon fergusdixon Oct 31, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have done, worked a charm, thanks @corymhall!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really want to ship this, but this property is giving me pause. I really don't see the need for it.

  • If you want the ECS controller explicitly, you can just supply it ("The customer is always right", below)
  • If you do NOT want the ECS controller, you can set the feature flag
    • If you want the ECS controller for some services and not other, you can either set the feature flag globally and add the explicit parameter to some services, or set the feature flag locally (you can flip a flag at any construct scope, it's all just context which is freely manipulable).

I think we can do without this, no?

Other than that, this is great!

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to cross-check "the need for the 'correct' default after this PR is merged": Now with current CDKv2 versions today, CFN output always has an ECS DeploymentController defined, if you have an CircuitBreaker enabled (even if you not aware as CDK user).
Once a stack has an ECS DeploymentController definied (= all stack build by CDK with CircuitBreaker enabled), you are not able to simply "remove this CFN-lines from JSON output" - If a new/upcoming CDK version would start to not output ECS DeploymentController (by default) to JSON, all existing Services of existing Stacks would run into a replacement - Just because you update your CDK version.

As I understood the current code from Fergus, this default = true would remain the same behaviour as older CDKv2 version, right? - From my point of view that, it's an important brick, isn't it?