#2736 PR merged: New EXCLUDE_IP_ADDRESSES and EXCLUDE_NETWORK_INTERFACES directives

Labels: enhancement, fixed / solved / done

rmetrich opened issue at 2021-12-28 17:09:

Relax-and-Recover (ReaR) Pull Request Template

Please fill in the following items before submitting a new pull request:

Pull Request Details:

  • Type: Enhancement

  • Impact: Normal

  • Reference to related issue (URL): N/A

  • How was this pull request tested? Manually

  • Brief description of the changes in this pull request:

These new array variables enable to ignore specific IP addresses or network interfaces when building the network configuration used in the rescue environment.
This is typically useful when floating IP addresses are used. Not ignoring these may lead to outage if the floating IP address is used by another system at time the system is getting recovered.

pcahyna commented at 2022-02-14 16:57:

Looks good, thanks - @rear/contributors , do you have an opinion on the variable naming? I checked the current variables and there is nothing called IGNORED_* but there are many EXCLUDE_* variables. As the present variables are for a bit different purpose than the EXCLUDE_* ones (those are for excluding stuff from backup, layout, or both, ditto *INCLUDE_*), I think the different name is acceptable. Shouldn't one use an imperative (IGNORE) instead of a participle (IGNORED) for consistency, though?

jsmeix commented at 2022-02-15 13:58:

We also use EXCLUDE named variables (in imperative grammar form)
to exclude things from the recovery system e.g. COPY_AS_IS_EXCLUDE.

We use nowhere IGNORE named config variables
except EXTERNAL_IGNORE_ERRORS which has a different meaning
than what IGNORED_IP_ADDRESSES and IGNORED_NETWORK_INTERFACES
are meant to do as far as I understand their description in default.conf
which actually means something like
"ignore them during recovery system build so they get excluded from the recovery system".

So I think renaming them into
EXCLUDE_IP_ADDRESSES and EXCLUDE_NETWORK_INTERFACES
explains better to the user what their actual meaning is.

rmetrich commented at 2022-02-16 09:18:

So I think renaming them into
EXCLUDE_IP_ADDRESSES and EXCLUDE_NETWORK_INTERFACES
explains better to the user what their actual meaning is.

👍

rmetrich commented at 2022-02-16 10:01:

Thanks for the comments, I will squash all this before merging once you are ok with this.

jsmeix commented at 2022-02-16 10:15:

@rmetrich
thank you for your prompt code cleanup and enhancements.
I reassign it to you so that you can merge it when you are ready for merging it.

pcahyna commented at 2022-02-16 10:35:

Just a thought: EXCLUDE_IP_ADDRESSES and EXCLUDE_NETWORK_INTERFACES are intended for the rescue image only. Do you think that there will ever be a need to exclude the addresses from the recovered system (i.e. permanently)? I would prefer to not have such transformations of the resulting system in ReaR, but there are some already (the various mapping rules and migration capabilities).

pcahyna commented at 2022-02-16 10:38:

@rmetrich thank you for quickly addressing the review comments. I think squashing the commits is appropriate. I keep separate commits when there is a logical need to do so (like, when in the same PR I do a cleanup of the old code, then I do functional changes, I keep the two separate), but it is not the case here.

jsmeix commented at 2022-02-16 11:01:

In general recreating a system different than it was before
belongs primarily to MIGRATION_MODE in ReaR.

If the values in EXCLUDE_IP_ADDRESSES and EXCLUDE_NETWORK_INTERFACES
are also intended for the recreated system some additional separated
config variable would be needed.

The current config variables that are related to migration are not named
with MIGRATE in their name so one has to search default.conf for places
that mention migrat (ignore case) to find what is related to migration.

The whole system migration area is currently not well implemented.
Something is done automatically mostly even hardcoded by scripts
so not at all any "final power to the user" in those cases.
Something can be specified via some config variables.
Something is just missing, cf.
https://github.com/rear/rear/issues/2312
and
https://github.com/rear/rear/issues/2468

For the not so fun of it:
As far as I remember some longer time ago
I tried to improve the automated networking migration code
cf. https://github.com/rear/rear/issues/2310
and https://github.com/rear/rear/pull/2313
in the recreated system but I basically got lost in that code
likely because I am not at all an expert in networking setup.
There is a reason why I prefer DHCP - my FritzBox router
and the KVM/QEMU virtualization environments
do the networking setup better than I can :-)

[Export of Github issue for rear/rear.]