Open chadbrewbaker opened 4 years ago
heitorlessa
commented
4 years ago Hey Chad - I'm not sure I got the ask, could you expand on the issue a bit on the problem and suggested solution?
Quickly glancing to the repo you mention I see two changes - Packer minor version bump and readme.
Perhaps this was created in error?
chadbrewbaker
commented
4 years ago Livecoding :) Once I get yaks shaved for ARM and bumping the kernel I'll send a PR.
heitorlessa
commented
4 years ago haha I know the feeling hence I thought I'd ask :)
On Wed, 25 Nov 2020 at 09:14, Chad Brewbaker notifications@github.com wrote:
Livecoding :) Once I get yaks shaved for ARM and bumping the kernel I'll send a PR.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/awslabs/ami-builder-packer/issues/16#issuecomment-733541966, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZPQBFQV3IQY6OTPFNYA5LSRS4HRANCNFSM4UCAJZUA .
Like to get some eyeballs on a builder to catch any mistakes. Ruby on Rails server - but could easily be .Net/JVM/Node/Django/RustRocket.
On the fence over the 5.4.20 kernel for awslinux2 or switch distros to Centos 8. Even the EKS AMI is broken on a lot of kubernetes tools from an old kernel.
Going with Graviton 2. Travis' benchmarks and my own M1 experience are overwhelming that x86 is toast.
Custom compile of the Ruby stack with FDO - source traceability on all gems as a build artifact.
Nginx, RDS compatible mysql 5.7 for local testing, SAM local for testing.
Task workers in a cgroup to limit blast radius of lurking media processing 0-days.
Source RPMs cached as artifacts cached to S3.
Anything that isn't production critical compressed with zstd to save space.
Deployment as EC2 batch for running tests - or giving devs a production parity instance they can ssh/vscode into from their laptop (especially with Docker hosed on M1, and this being ARM which would hose x86 WSL2).