On Mon, Nov 3, 2014 at 7:25 PM, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: > On Mon, Nov 03, 2014 at 05:53:21PM -0500, David Gay wrote: >> ----- Original Message ----- >> > From: "Joe Brockmeier" <jzb@xxxxxxxxxx> >> > To: cloud@xxxxxxxxxxxxxxxxxxxxxxx >> > 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 _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
