[josephruscio]

Canonical maintains and updates their own AKIs for their official Ubuntu AMIs, which is what we're running in production. I suggest deferring to their judgement. Here's a full release history of the Ubuntu 10.04 server AMI's, note the changing AKIs and note that none of them are the default ones provided by Amazon:

http://uec-images.ubuntu.com/query/lucid/server/released.txt

[moe]

And their rationale for doing that is?

Looks like their judgement didn't work out so well this time. I'd be wary of running the latest untested kernel for no reason other than "because we can".

[mihasya]

So Canonical, a distribution maker, is not to be trusted for their kernel suggestions, but Amazon is infallible? On what basis?

We asked the Amazon kernel team if we should try switching to one of their kernels/distros, and they said "No, just upgrade to Maverick and the accompanying kernel." It's been pointed out that Maverick has its own set of Xen bugs. I guess Amazon doesn't know everything.

The horse you're getting on about using the "proven" Amazon kernels is a bit high. Turns out this whole virtualization thing is somewhat new, and the kinks are still being worked out. Old kernel builds don't work particularly well because a lot of their assumptions are broken by virtualization; new kernels are what they are - new.

(Edit, forgot initially): Finally, we ran 10.04 - the Long Term Support release of Ubuntu from a year ago. There was no "because we can."

Frankly, I'm a bit amazed at your disdain for people sharing their findings from practical experience running into these issues in high-load production environments.

[moe]

So Canonical, a distribution maker, is not to be trusted for their kernel suggestions, but Amazon is infallible?

Neither is infallible. But Amazon probably knows the intricacies of their platform better than Canonical. And they likely run some of their own stuff on these kernels for a while before releasing them to the public.

Old kernel builds don't work particularly well

Don't work as in what? This is the first time I hear about a kernel problem on EC2.

disdain

I don't see where I voiced disdain. I merely responded to the guy who claimed your EC2 kernel is linked to the distro you run. That's simply not true.

[mmalone]

If this is the first time you've heard about a kernel problem on EC2 you're probably not managing a very large EC2 infrastructure [1, 2]. Even in non-virtualized environments, at scale, it's common to run into linux kernel bugs, or at least peculiarities. Which is why large tech organizations invariably employ kernel dev teams.

The guy who claimed EC2 kernels are linked to the distro you run was simply claiming that, unless you want to go it on your own, you're tied to the kernel provided by a supported AMI. As you've suggested multiple times, there are benefits to running an environment that is supported and that other people have operational experience with. Honestly, I'm not even sure what you're arguing anymore... seems like you're just being antagonistic.

[1] https://bugs.launchpad.net/ubuntu/+source/linux-ec2/ [2] https://bugs.launchpad.net/ubuntu/+source/linux/+bugs?field....

[moe]

unless you want to go it on your own

There are plenty AMIs based on stable AKIs out there. Moreover if you manage a "very large EC2 infrastructure" then you don't rely on 3rd party AMIs, do you?

Finally, your links point to... Ubuntu bugs. If I missed one that was tracked back to an amazon AKI then a deeplink would be appreciated.