Add Amazon ECS clustering for Docker

[grkvlt]

Creates a cluster of Docker Engines for use with Amazon ECS, running the ECS agent to register with the container service. Scaling and service replacement is managed by Brooklyn.

[grkvlt]

The screenshot below shows what an ECS cluster managed by Brooklyn looks like in the AWS console, with one task running.

[aledsage]

We really must have tests for anything like this. We can't merge more and more functionality without being able to do automated regression testing.

Can you please add tests that use org.apache.brooklyn.test.framework (so that it can be run in a QA Framework). Without that, we should not consider merging this.

[aledsage]

docker-cluster seems a strange name for this, to add to the catalog. We'll have lost the context that it is for EC2 container service. We should probably have "ecs" in the catalog item id.

[grkvlt]

Agree

[aledsage]

It's scary that we're repeating all of these brooklyn.parameters in different entities in this same file.

What is the purpose of having ecs-cluster and docker-cluster as separate items?

[grkvlt]

It's the pattern used for all other Clocker templates. The way to avoid the duplication of parameters is to have some way of defining them as displayable, since this is just to have a subset that show up in the add application wizard...

[neykov]

@grkvlt We can already define parameters as displayable by using the pinned flag. pinned: true which is the default means show the item in UI. Set it to false to hide.

[grkvlt]

@neykov this is almost what we want; but was really looking for a way of indicating that a particular parameter defined in some child entity is to be displayed in the UI when a catalog entry that references that child is created? i.e. the Swarm TCP port is a property defined on the swarm-manager entity, but we want to propagate that up to the top level as an application configuration option.

[neykov]

I see what you mean now. Agree it would be nice to be able to express this case in a more concise way.

[aledsage]

Will this cause us to track an infinite history of cluster load, so that we try to calculate what load has been happening "forever"? (I haven't dug into the Brooklyn AutoScalerPolicy to check; if you're going to rely on this, then perhaps we should have a test in Brooklyn? Or maybe we should just add an explicit autoscaler.resizeDownEnabled: false).

[grkvlt]

Interesting, not sure. We should definitely check, as this is part of the Swarm and Kubernetes autoscalers too.

[grkvlt]

@aledsage I had a closer look at this, and you're right. Since resizeDownIterationMax is zero, the delta for scale-down will always be zero, so the desired size is always equal to current size and scheduleResize(int) is never called to add a new smaller size. However this doesn't matter, as there is only one SizeHistory object, containing a TimeWindowedList sized to the Duration.of("forever") maximum.

long maxResizeStabilizationDelay = Math.max(getResizeUpStabilizationDelay().toMilliseconds(), getResizeDownStabilizationDelay().toMilliseconds());
recentDesiredResizes = new SizeHistory(maxResizeStabilizationDelay);

So, this should probably be changed to zero (i.e. removed, since that is the default value) as well, then the TimeWindowedList will be created using the desired resizeUpStabilizationDelay value. And, as noted above, this ought to be done for the Swam and Kubernetes auto-scalers as well.

[aledsage]

Does this assume CentOS 6? I'd have thought we'd want firewalld for CentOS 7.

[grkvlt]

Based on the ECS instructions for installing the agent

[grkvlt]

@aledsage what tests would you suggest? The ECS agent will fail on startup if an ECS cluster is not available with the provided name.

[grkvlt]

@aledsage I added tests that both check service up and also verify that custom sensors have correct values, this should be good to merge?