Revert ac2b3983eede591bc37ad6b97f1de06d9be05781

[benbp]

Reverts #31

From #31

well crud. -1 -1 -1 -1 -1 -1 -1
The issue that spawned this wasn't fixed by it in the real deployment. In fact, during deployment testing, the .ifname=0 (going back to trusting the old-style kernel names) showed inconsistent naming during installs: a few times eth0 got mapped to the first mez card, most other times it got mapped to the 2nd mez.

We need to revert this, since it will also mess up regression tests because of the name changes again.

@pengz1 @keedya @yyscamper @zyoung51 @stuart-stanley

Redirect questions to me to @stuart-stanley, it just seems he doesn't have permissions to create the revert PR so I'm doing it for him :)

[benbp]

@stuart-stanley do we still need this?

[stuart-stanley]

Yes. For some reason I thought it had gone. The sooner the better...

[benbp]

Ok, can you drive getting reviews on this?

[stuart-stanley]

@benbp sure...
Please review!!!
Description of change:
This reverts a change made to attempt to resolve a specific deployment problem. The initial commit being backed out turned off consistent naming and also removed all ifcfg-* scripts before generating the configuration file(s) for the interfaces defined in the install. This meant interfaces where named using old-style kernel names (eth0, eth1, ...)
The code was merged before it was tested in the deployment environment. When it was tested, it turned out not to address the problem and generated other problems in terms of having what piece of hardware the kernel chose as 'eth0', etc, change.
The revert puts the system behavior back to what it was initially (and what has now been tested in the deployment in question).

Possible reviewers for this would be @zyoung51 (did initial parameterization) or @davidzuhn (familar with larger rhel installs). @benbp for core committer who did the initial merge probably makes sense too :)

[zyoung51]

👍 on reverting. Is the follow-on fix already submitted/planned?

[stuart-stanley]

@zyoung51 yes and no :). The current code wasn't actually broken, per-se, so nothing immediate is needed. Making the network configs more robust in general will probably show up as thing(tm) before too long though. (btw, the problem was connected to using Netmanger.service and network.service (initscript based config) at the same time. RH says it's supposed to work, but it didn't for the RHEL7 beta release, at least for our situation. I was honestly a bit surprised that it turned out TO work on for the GA release. So the original commit was basically trying to trick the configuration around the problem in the beta...

[heckj]

@zyoung51 @stuart-stanley @benbp what's the status on this PR - are we reverting? It's been open for a few days now, wasn't clear on where it was heading...

[stuart-stanley]

Yes. Again, for some reason I had thought it had gone once we had core +1
+1 for me, if that matters (not sure if I should count), but this should not have gone in to begin with.

[jlongever]

👍