On Sat, Jul 14, 2018 at 3:11 PM, Henry Finucane h.finucane@gmail.com wrote:
On Sat, Jul 14, 2018 at 5:22 AM Nico Kadel-Garcia nkadel@gmail.com wrote:
See above. Also, the base CentOS 7 3.10.0 kernel is becoming a bit dated: it's 5 years old now. If you have time: can you set up a smaller instance, do kernel updates on top of a CentOs 7 AMI, and see if *that* AMI is compatible with the new instances? Might make for an interesting test and get you a working AMI.
I did this with CentOS 6 at some point, and it's worth noting that you'll have to build your own AMI from scratch, you can't just update the existing AMI- the base AMI's lack of support "taints" derived ones.
There Are Ways(tm). One of my favorite is to link a LiveDVD image to the VM built from the messed up or out of date OS image, mount the storage for the messy host, and do the updates on a chroot cage to *that*. In this case, there instances of the same class, just different sizes, that are apparently tested and approved. I'd stage a build to one of the approved instance types and do the updates *there*, then take a snapshot.
I used packer's chroot builder, it was pretty reasonable and you can find examples online to help you get started.
Heh. I wrote tools that did something like this for hardware testing, creating a base tarball image much like "mock" does and applying it to new hadware configurations from DHCP and kickstart, and even one that could be downloaded and run to upgrade from a local tarball. That was in... 2000, and was used on roughly 20,000 systems that year for an OS update. It's still faster than most virtualization "disk image" based clones from a golden image.