Added support for os-family attribute to be advertised by the agent for fine grained task placement

[rawahars]

Summary

A new attribute is being introduced in the ECS Control plane called ecs.os-family which defines the os family to which the instance belongs. For Linux based instances, the OS family would be advertised as linux and for Windows based instances, the attribute would have a value of format - WINDOWS_SERVER_<Windows Version>_<Installation Type>

This would allow the customers to achieve fine grained task placement especially in a mixed cluster.

Example- If a cluster runs instances running on different Windows versions, and a task definition specifies the OS family as WINDOWS_SERVER_2019_FULL then this task would only be placed on the instances which broadcasted their os-family as WINDOWS_SERVER_2019_FULL.

Implementation details

A new attribute has been introduced ecs.os-family. The values for Linux based instances is linux.
For Windows instances, the value can be-
WINDOWS_SERVER_2019_FULL, WINDOWS_SERVER_2019_CORE, WINDOWS_SERVER_2016_FULL, WINDOWS_SERVER_2022_FULL, WINDOWS_SERVER_2022_CORE, WINDOWS_SERVER_2004_CORE, WINDOWS_SERVER_20H2_CORE

Testing

Unit tests have been added and existing tests were updated.
Additionally, custom AMIs with custom agent built from this branch was tested to ensure that the instance can register itself to the cluster.

New tests cover the changes:
Yes

Description for the changelog

Added support for OS Family to the agent.

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[fenxiong]

looks good few nits

[fierlion]

good overall test coverage!

[singholt]

Just curious - What happens if a customer tries to use both os-type and os-family attributes at once, and they conflict? Example - os-type = "linux" and os-family = "windows-2019...". Do we want to add checks for such a scenario, even if it may be accidental?

not sure if agent is the right place for such validation. thinking out loud

[rawahars]

@singholt With respect to the conflicting task placement constraints such as-

"placementConstraints": [
    {
      "type": "memberOf",
      "expression": "attribute:ecs.os-type == linux"
    },
   {
      "type": "memberOf",
      "expression": "attribute:ecs.os-family == WINDOWS_SERVER_2019_FULL"
    }
  ]

The run task call itself will fail with an error message such as Reasons : ["MemberOf placement constraint unsatisfied.","AGENT"]. Learn more

This is the existing behavior with any task placement constraint using the custom attribute tags. If there isn't any instance which matches both the constraints, the task would fail.

[singholt]

@singholt With respect to the conflicting task placement constraints such as-

"placementConstraints": [
    {
      "type": "memberOf",
      "expression": "attribute:ecs.os-type == linux"
    },
   {
      "type": "memberOf",
      "expression": "attribute:ecs.os-family == WINDOWS_SERVER_2019_FULL"
    }
  ]

The run task call itself will fail with an error message such as Reasons : ["MemberOf placement constraint unsatisfied.","AGENT"]. Learn more

This is the existing behavior with any task placement constraint using the custom attribute tags. If there isn't any instance which matches both the constraints, the task would fail.

I agree. I'm thinking around whether we want to fail early, at register-task call?

[rawahars]

ECS doesn't fail the register-task call even if we specify any random value for the task placement constraint attribute. For example, we can register a task definition with say the below placement constraint. The task would be failed during run-task.

"placementConstraints": [
    {
      "type": "memberOf",
      "expression": "attribute:ecs.os-type == invalidOS"
    }
  ]

The same is applicable for any conflicting attributes.

[singholt]

ECS doesn't fail the register-task call even if we specify any random value for the task placement constraint attribute. For example, we can register a task definition with say the below placement constraint. The task would be failed during run-task.

"placementConstraints": [
    {
      "type": "memberOf",
      "expression": "attribute:ecs.os-type == invalidOS"
    }
  ]

The same is applicable for any conflicting attributes.

thanks, makes sense