help needed

[Tim Flink]

On Fri, 30 Mar 2012 16:54:47 -0400
Andy Grimm <agrimm at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/cloud/attachments/20120330/3989b6bc/attachment.sig>