On Fri, Mar 30, 2012 at 5:35 PM, Tim Flink <tflink@xxxxxxxxxx> wrote: > On Fri, 30 Mar 2012 16:54:47 -0400 > Andy Grimm <agrimm@xxxxxxxxx> wrote: > >> Of those differences, I suspect that lack of a zeroconf route >> (169.254.0.0/16) is probably preventing access to the metadata >> service. Further, I believe the reason is related to the addition of >> NetworkManager in the F17 AMI (because the zeroconf route is typically >> added via the ifcfg-eth script, which NM does not run). Before I go >> hacking further, is there a particular reason that we switched to >> using NetworkManager in the F17 AMI? > > NM was added to core as a fix for a F17 bug where the network wouldn't > come up by default in a minimal install: > - https://bugzilla.redhat.com/show_bug.cgi?id=693602 > > The decision was made to add NM to core because it doesn't add many > extra packages and as NM adds more and more features, it doesn't make > much sense to keep hacking the old network service in for minimal > installs. The full details of "why" are in the bug, if you're > interested. Ok, I've been on the CC list for that bug for a long time, but I missed that they actually made a decision. I'll just bite my tongue on that one; at least it's not completely broken anymore. > maxamillion did a good job of summing up some of the you can do about > removing/replacing NM for a regular system in his blog post: > http://pseudogen.blogspot.com/2012/03/networkmanager-is-in-core-but-dont-fret.html Thanks for that link! >> Would removing it be the wrong solution, and if so, is there a quick >> way to ensure that NM initializes a zeroconf route? > > That is certainly possible, the network service still works. It just > made more sense to use NM for non-cloud minimal installs. > > I'll leave the discussion of the best way to deal with NM/network to > people who are far more qualified than I am. Just figured I would add > in the answer to "why did this change?" As it turns out, I just booted an Ubuntu Oneiric instance, and it does not have a zeroconf route, but is still able to access the metadata service, so it looks like this was a red herring. Back to the drawing board. --Andy > Tim > > _______________________________________________ > cloud mailing list > cloud@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/cloud > _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
