Split ECS and VPC CNI plugins from ecs-agent

[koooosh]

Issue number: #90

Closes #90

Description of changes:

Currently, the ecs-agent pkg also includes the amazon-ecs-cni-plugins and amazon-vpc-cni-plugins submodules (source) which are built along with it. Ideally, we want to split these plugins into their own packages for ease of building and patching.

This PR splits the amazon-ecs-cni-plugins and amazon-vpc-cni-plugins submodules from the ecs-agent package into their own separate packages.

The plugin binaries are installed in the /usr/libexec/cni/ path and have symlinks in /usr/libexec/amazon-ecs-agent/ for the ecs-agent to access.

Testing done:

• Both aws-ecs-1 and aws-ecs-2 variants build and boot successfully.

• Binaries and symlinks are installed correctly:

bash-5.1# ls -l /usr/libexec/amazon-ecs-agent/
total 4
lrwxrwxrwx. 1 root root   22 Aug 15 09:06 aws-appmesh -> ../cni/vpc/aws-appmesh
lrwxrwxrwx. 1 root root   21 Aug 15 09:06 ecs-bridge -> ../cni/ecs/ecs-bridge
lrwxrwxrwx. 1 root root   18 Aug 15 09:06 ecs-eni -> ../cni/ecs/ecs-eni
lrwxrwxrwx. 1 root root   19 Aug 15 09:06 ecs-ipam -> ../cni/ecs/ecs-ipam
lrwxrwxrwx. 1 root root   29 Aug 15 09:06 ecs-serviceconnect -> ../cni/vpc/ecs-serviceconnect
drwxr-xr-x. 3 root root 4096 Aug 15 09:08 managed-agents
lrwxrwxrwx. 1 root root   25 Aug 15 09:06 vpc-branch-eni -> ../cni/vpc/vpc-branch-eni
lrwxrwxrwx. 1 root root   21 Aug 15 09:06 vpc-bridge -> ../cni/vpc/vpc-bridge
lrwxrwxrwx. 1 root root   18 Aug 15 09:06 vpc-eni -> ../cni/vpc/vpc-eni
lrwxrwxrwx. 1 root root   21 Aug 15 09:06 vpc-tunnel -> ../cni/vpc/vpc-tunnel

• ECS service is running successfully:

bash-5.1# systemctl status ecs
● ecs.service - Amazon Elastic Container Service - container agent
     Loaded: loaded (/x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/system/ecs.service; enabled; preset: enabled)
    Drop-In: /x86_64-bottlerocket-linux-gnu/sys-root/usr/lib/systemd/system/ecs.service.d
             └─00-defaults.conf
             /etc/systemd/system/ecs.service.d
             └─10-base.conf
     Active: active (running) since Thu 2024-08-15 09:10:06 UTC; 25min ago
       Docs: https://aws.amazon.com/documentation/ecs/
   Main PID: 2080 (amazon-ecs-agen)
      Tasks: 10 (limit: 18928)
     Memory: 81.9M
     CGroup: /system.slice/ecs.service
             └─2080 /usr/bin/amazon-ecs-agent

• Internal testing for aws-ecs-1 variant succeeds.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[koooosh]

Force push addresses @arnaldo2792 comments:

• Builds all VPC CNI plugins
• Updates patch number in ecs cni spec
• Few nit fixes in ecs agent spec

[larvacea]

Despite my confusion (1001-something.patch is not 0001-something.patch), looks fine to me.

[bcressey]

nit: you can drop pkg and pkgs from the commit messages; the "packages:" prefix implies that you're working with packages.

Overall this seems like a reasonable change - generally sources with different upstreams should be packaged separately - but there's no rationale provided, either in the commit messages or in the pull request summary. It's obvious what you're doing (splitting up a package) but not why.

[bcressey]

It's very strange for a package to symlink another package's binaries like this, and to vend those symlinks. I acknowledge that it was done for the SSM agent plugin but it's not a great pattern to emulate. It would be better to create these links in the corresponding CNI package. You could put them in an "ecs" subpackage, but that's not as important as keeping the links and binaries together.

Some concerns with this approach:

• If a new VPC or ECS plugin is added, this package definition must also change in order to create symlinks. Where if the plugin package also owns the symlink, then it will be more obvious to the packager that this dependency exists.
• This will create broken symlinks, if the plugin package drops a plugin or changes the path where plugins are installed.

[koooosh]

Ack regarding dropping pkg* from commit messages - will fix those. Regarding rationale, I put that in the issue #90 :

Ideally, we want to split these plugins into their own packages for ease of building and patching.

But I'll copy that over to this PR description!

[koooosh]

Good callouts regarding the symlinks. My (naive) reasoning was that since they are being installed in the /amazon-ecs-agent directory, they should be added to the amazon-ecs-agent spec, but I agree this will cause more maintenance issues in the future. Will create these symlinks in their respective pkg as suggested.

[koooosh]

Force push makes the following relevant changes:

• Moves the creation of ECS and VPC CNI plugin binary symlinks to their own respective pkgs instead of the ecs-agent pkg

[koooosh]

Force push changes symlink subpackaging to better match repo convention like here

[koooosh]

Force push makes the following changes:

• Removes unnecessary subpkgs
• Renames symlink subpkgs

[koooosh]

Force push updates FIPS symlink paths to point to binaries in /usr/fips/libexec rather than usr/libexec