[Manifest] Allow TaskDefinition overrides in the Manifest

[kohidave]

The manifest provides a great set of high level knobs for folks to configure their services.

Beyond that - it also provides environment based overrides.

There are some things that are harder to abstract away which are super useful to folks (readOnlyRootFilesystem, as an example, is hard to model - but important to some folks).

We propose a new section of the manifest:

taskdef:
  ContainerDefinition:
    my-fe-service:
      ReadonlyRootFilesystem: true

These additions are additive.

[efekarakus]

Nice! Is this going to only change the container definition for the service container?
Or do you foresee being able to add any fields in the task definition? If so we might need to figure out a way of dealing with lists.

[kohidave]

Nice! Is this going to only change the container definition for the service container?
Or do you foresee being able to add any fields in the task definition? If so we might need to figure out a way of dealing with lists.

I see this as being able to update any field in the task def. We'll essentially generate our own task definition using the manifest - then merge in these fields from the customer's task definition.

[efekarakus]

Gotcha that makes sense to me!

[kohidave]

Also a customer just reached out with this request:

Hi guys, using the CLI, how would you define ulimit?
I tried to deploy my webapp which is using apache image and got this in the logs:
/usr/sbin/apache2ctl: 87: ulimit: error setting limit (Operation not permitted)
Setting ulimit failed. See README.Debian for more information.
I want to set something like:

"ulimits": [
        {
          "softLimit": 2048,
          "hardLimit": 2048,
          "name": "nofile"
        }

[efekarakus]

One thing that'd be cool that only task definition overrides wouldn't allow is override service specific parameters as well. For example, a customer requested being able to use PV 1.4.0 instead of the current $LATEST

[jonchase]

(copying from the gitter conversation) Cool, thanks for the clarification. To be clear, 1.3.0 is fine with me - I just wasn't sure if I was getting 1.3.0 b/c of something I had done, or something on the copilot/AWS default side.

[efekarakus]

Hi folks! @iamhopaul123 posted a design proposal for this feature here: #2588

[efekarakus]

This feature was delivered in v1.10.0 🎉 ! Closing it here: https://github.com/aws/copilot-cli/releases/tag/v1.10.0