32 bit AMI registration boot problem: explaination and possible solutions

[Andy Grimm]

On Mon, Nov 3, 2014 at 7:25 PM, Dusty Mabe <dusty at dustymabe.com> wrote:
> On Mon, Nov 03, 2014 at 05:53:21PM -0500, David Gay wrote:
>> ----- Original Message -----
>> > From: "Joe Brockmeier" <jzb at redhat.com>
>> > To: cloud at lists.fedoraproject.org
>> > Sent: Monday, November 3, 2014 2:47:00 PM
>> > Subject: Re: 32 bit AMI registration boot problem: explaination and possible        solutions
>> >
>> > On 11/03/2014 04:43 PM, David Gay wrote:
>> > > I'm with you on that. I don't know many people who use 32 bit cloud
>> > > images. 64 bit is available for every EC2 instance type, and like you
>> > > said, other services support it. I'm likely not the best person to ask
>> > > why we provide 32 bit images, though. It could be a legacy thing, but it
>> > > might also be habit.
>> >
>> > I'm +1 to dropping 32-bit unless someone has a good reason why we're
>> > doing them...
>> >
>> > Best,
>> >
>> > jzb
>>
>> +1 from me, as well.
>
> I would love to get rid of the 32bit AMIs. That being said, is this a "knee jerk"
> reaction? Typically it's best to make changes like this with planning involved
> and sufficient notice of the change so the community can prepare.
>
> Again, I'm all for getting rid of them. Just want to make sure we think about everything.

My rambling thoughts on this:

Do we have _any_ analytics on usage?  (launch stats from AWS, or
unique IPs hitting Fedora mirrors inside AWS, or ...)

I don't have any strong reason to want to keep it; I don't run 32-bit
anything.  But given that we do still formally support the arch in the
distro, I don't like knowing that it's completely broken.  If it can
be made to work (without undue burden on the kernel folks, who
certainly have better things to do), we should.  Blocking the beta on
this if other 32-bit installs work does not seem necessary to me,
though.

FWIW, there are only 4 AWS instance types where 32-bit is supported
(t1.micro, m1.small, m1.medium, and c1.medium), and what's _really_
funny is that none of them have more than 3.7 GB or RAM (so PAE serves
no purpose).  It seems like the use case for these would be pretty
narrow, given that the price/performance of m3 and t2/t3 are generally
better.  As Garrett likes to remind us, there's the large ephemeral
disk factor on the m1/c1 types, but I don't know how many people care
about that.

As for how to actually deal with the problem, since the system is
booting and just doesn't appear to be getting a network connection, I
suspect we can add some debugging info at boot-time to figure out
what's going on.  I'll try to come up with a script that'll dump some
useful data to the console for us.  That could be generally useful,
anyway.  (cloud-init already does some of this, except that it doesn't
ever get run if the NIC isn't present)

--Andy