Created attachment 1221903 [details]
remove INFERRABLE flag from dhcp-hostname

When NM is shut off, it will leave the connections up.
When it starts it will check if network devices are already configured: if so, it will assume the connection, mapping it to a new, on-the-fly generated connection retrieving the configuration data from the system.
Once this has been done, it will look among the connections saved on disk if there is one matching the properties of the assumed one.
Properties that should be considered in the match are flagged as INFERRABLE.

DHCP_HOSTNAME is mapped to the ip "dhcp-hostname" property, which is marked as "INFERRABLE". Anyway, the dhcp-hostname is not "inferred" from the system when NM starts.
So, the issue here is that when NM is restarted, the connection it "infers back" has empty dhcp-hostname property, triggering the failure with the on-disk one.

There are two options here:
1) try to retrieve the sent hostname from the dhcp client configuration file
2) remove the INFERRABLE flag from that property, so it will not be included in the checks between generated vs on-disk connection

I cannot envision a realistic scenario that could benefit from option 1), moreover option 2) is trivial: attaching a patch for option 2) here.

(In reply to Francesco Giudici from comment #2)
> Created attachment 1221903 [details]
> remove INFERRABLE flag from dhcp-hostname

LGTM

Merged to upstream master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=0ce7da1e22abf7a4415ef40fca9f1755b8ddfa30

Case - 1733309 - On this case, after the Network Manager is restarted NetwrokManager creates new in-memory connection which have wrong parameters, which don't have  ipv4.dhcp-hostname parameter set, so after DHCP lease expire DNS server lost DNS client record.

Associated BZ - 1393997

Fransesco is assigned to this BZ and this is merged to upstream master at the moment. The status  - Modified

Customer mentioned that they does not want a hotfix and would like to see the fix on RHEL 7.2 EUS channel

@Chris & @Fransesco - Can we get an update on this and more importantly whether we would have a fix on the RHEL 7.2 EUS channel at the earliest?

Thanks,
Praveen
Escalation Manager

(In reply to Praveen Varma from comment #6)
> Case - 1733309 - On this case, after the Network Manager is restarted

May I ask why NetworkManager is restarted?
If it is just to update the connection list for newly added config files the proper way is:
"nmcli connection reload"
and the new connection can be applied with
'nmcli connection up $conn_name'

> NetwrokManager creates new in-memory connection which have wrong parameters,
> which don't have  ipv4.dhcp-hostname parameter set, so after DHCP lease
> expire DNS server lost DNS client record.

Appending '&& nmcli connection up $conn_name' to the NetworkManager restart command will allow NetworkManager to apply the stored connection overriding the one which has been found.
Anyway, my first advice would be to stick with the "reload" command above.

Please can you share why NetworkManager should be restart?
This should be avoided whenever possible to avoid side effects.

> 
> Associated BZ - 1393997
> 
> Fransesco is assigned to this BZ and this is merged to upstream master at
> the moment. The status  - Modified
> 
> Customer mentioned that they does not want a hotfix and would like to see
> the fix on RHEL 7.2 EUS channel
> 
> @Chris & @Fransesco - Can we get an update on this and more importantly
> whether we would have a fix on the RHEL 7.2 EUS channel at the earliest?
> 
> Thanks,
> Praveen
> Escalation Manager

Thank you Fransesco for your comments.

1) I think we should be first talking to the customer about this and then decide if they are ready look at a backport option for their needs (after they are let known that the restart of NM is not advisable) - We would come back to let you know the decision

2) If the decision is to backport, can we make sure that this is taken care in 7.2 EUS? If so, by when can it be done?

Thanks again for your support Fransesco !!

Regards,
Praveen

(In reply to Praveen Varma from comment #9)
> Thank you Fransesco for your comments.
> 
> 1) I think we should be first talking to the customer about this and then
> decide if they are ready look at a backport option for their needs (after
> they are let known that the restart of NM is not advisable) - We would come
> back to let you know the decision

Great, thanks!

> 
> 2) If the decision is to backport, can we make sure that this is taken care
> in 7.2 EUS? If so, by when can it be done?

I guess to have this in 7.2 EUS the bug should be cloned by a PM for 7.3 and 7.2 EUS and should be accepted. Please, share the user scenario that requires NetworkManager to be restarted: this would help.
I'm not able to estimate the time this could take as it is not under my control.
Once the bugs are created and accepted then I can update the code for the RHEL packages quickly.

Thanks!

Francesco

> 
> Thanks again for your support Fransesco !!
> 
> Regards,
> Praveen

Francesco - hope you have seen the comments from Robin which he received from the customer. Do you have some info to share on this?

Thanks in advance !!

Regards,
Praveen

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2017:2299