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. 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 > 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?" Tim
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud
