Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: bring up down interfaces #126

Open
esalberg opened this issue Jun 5, 2017 · 4 comments
Open

Feature: bring up down interfaces #126

esalberg opened this issue Jun 5, 2017 · 4 comments

Comments

@esalberg
Copy link
Contributor

esalberg commented Jun 5, 2017

Currently, the network service only refreshes if the ifcfg file changes. If an interface (e.g. a VIP) is configured but not up, the module does not bring up the interface.

It should be possible to check the networking fact for interfaces and run ifup (for ensure: up) or ifdown (for ensure: down), versus relying just on the ifcfg file presence / absence and refreshing the entire network service. E.g. bringing up a VIP shouldn't have to disrupt the entire network service.

I'll try and put together a PR, but let me know if this isn't a good idea / not worth the work.

@razorsedge
Copy link
Owner

The reason that I decided to use the big hammer (ie service network restart) is that it has all of the magical dependency stuff built in and I did not want to have to reimplement all of that in this module.

For example: Which happens first, route removal or interface down? For all interface types?

I'm not saying not to implement this. Just that I deemed it difficult/error-prone/already-implemented-elsewhere at some point in the past (EL5 maybe?).

@esalberg
Copy link
Contributor Author

I agree in theory, but shouldn't using the ifup / ifdown system scripts handle the dependencies, at least for basic interfaces (e.g. ones using ifcfg-eth#)? I have no issue limiting the scope here, and I don't have experience in all the platforms covered by the module.

Right now, we have the network restart completely disabled, which removes risk for nodes like database servers not having their network restarted, but also means that network files get updated but nothing actually gets implemented, which is kind of beside the point.

I considered trying to add some sort of scheduling in there (e.g. only implement changes / restart the network "after hours"), but I wasn't sure that was the right complexity to add. Thoughts?

Ideally, I'd like to be able to configure what would normally be non-disruptive network changes during the day. Currently, it's either all network changes are disruptive (and thus have to be held for after hours), or no network changes are disruptive but the interface has to be brought up/down by hand.

@razorsedge
Copy link
Owner

Defining what network changes are to be considered non-disruptive is not something that this module can do.

However, giving people the flexibility to define and control those events seems to be a good idea. I actually looked through the /etc/init.d/network, /sbin/ifup, and /etc/sysconfig/network-scripts/ifup-* scripts and after sitting in a dumb stupor for a while I have decided that supporting ifup/ifdown on each separate interface can't be any worse. :-)

One of the recently merged PRs add the restart parameter to a number of defines. We might be able to either switch out the notify to trigger ifup instead of "service network" or maybe add a parameter to network::global to determine ifup instead of "service network".

@esalberg
Copy link
Contributor Author

See #133

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants