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

Added ECS PlacementConstraints, PlacementStrategy, and ServiceName #706

Merged
merged 14 commits into from May 2, 2017

Conversation

ktruckenmiller
Copy link
Contributor

Added placement strategies and placement constraints for the ecs services.

We could also add this to task definitions.

Let us know if you'd like to do that and we can add it

@ktruckenmiller ktruckenmiller changed the title Added ECS Constraints Added ECS PlacementConstraints, PlacementStrategy, and ServiceName May 1, 2017

class PlacementStrategy(AWSProperty):
props = {
'Type': (basestring, True),
Copy link
Member

Choose a reason for hiding this comment

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

Looks like we both added this, so I closed mine (#707). You could add validation on the Type field here that it's one of the allowed random, spread, binpack.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I was adding that, but then I noticed that they had no other validators of this type. I could definitely do this, I wanted to see what cloudtools suggests

Copy link
Member

Choose a reason for hiding this comment

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

Yeah, I think there's a mix of validation when it's simple, like in emr, and just a basestring in others, so there's not really 100% consistency. IMHO, it's always nice to have early validation, but I can also see the argument that it's more future-proof to let cloudformation be the validator.

Copy link
Member

Choose a reason for hiding this comment

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

Quite a bit of the validation was put in later in the project and there has never been an effort to go back to add it. If there is an easy way to constrain the value it is always good to add it now. This can be done like the emr examples of using a function instead of basestring, or easier by adding a validate() method to the object. The former will validate at object creation time and the latter at template creation time. I'm fine with either since that is better than having stacks rollback with illegal options.

@@ -35,6 +65,9 @@ class Service(AWSObject):
'DesiredCount': (positive_integer, False),
'LoadBalancers': ([LoadBalancer], False),
'Role': (basestring, False),
'PlacementConstraints': ([PlacementConstraint], False),
Copy link
Member

Choose a reason for hiding this comment

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

I think the convention is for these props to be alphabetical. The Placement... ones should probably be moved above Role.

@markpeek markpeek merged commit 60b0ea1 into cloudtools:master May 2, 2017
@markpeek
Copy link
Member

markpeek commented May 2, 2017

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants