RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1525078 - [NMCI]add MASTER=dev when creating bond directly with slaves in nmtui
Summary: [NMCI]add MASTER=dev when creating bond directly with slaves in nmtui
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Beniamino Galvani
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On: 1425409
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-12-12 14:59 UTC by Vladimir Benes
Modified: 2018-04-10 13:37 UTC (History)
10 users (show)

Fixed In Version: NetworkManager-1.10.2-4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1425409
Environment:
Last Closed: 2018-04-10 13:35:58 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
[PATCH] settings: clear unsaved flag on new settings-connection (5.72 KB, patch)
2017-12-15 20:44 UTC, Beniamino Galvani 		no flags Details | Diff
[PATCH v2] settings: clear unsaved flag on new settings-connection (8.33 KB, patch)
2017-12-20 09:00 UTC, Beniamino Galvani 		no flags Details | Diff
Show Obsolete (1) View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:0778 0 None None None 2018-04-10 13:37:11 UTC

Comment 4 Beniamino Galvani 2017-12-15 20:44:43 UTC 
Created attachment 1368684 [details]
[PATCH] settings: clear unsaved flag on new settings-connection
Comment 5 Thomas Haller 2017-12-19 15:29:18 UTC 
(In reply to Beniamino Galvani from comment #4)
> Created attachment 1368684 [details]
> [PATCH] settings: clear unsaved flag on new settings-connection

> We could add a new persist-mode enum, but let's keep it simple and
> just clear the flag after the update.


<thaller> regarding "settings: clear unsaved flag on new settings-connection"...
<thaller> maybe we should instead add a new persist-mode enum
<thaller> because, I added logging whenever the flags change (I think that is useful). but this results in two log messages that are noise.
<bengal> I was in doubt whether to add an enum and opted to clear the flag because it seemed simpler. But it's true that this results in two update messages...
<bengal> okay, i'll try to add an enum
<thaller> yes, the number of flags are already complicated enough... but I dislike the logging messages, and I also dislike a bit that temporarily the flags are in a wrong state (probably nobody cares, but update() is such a complex function, emitting a changed signals, it's not clear to me that nobody cares)
Comment 6 Beniamino Galvani 2017-12-20 09:00:36 UTC 
Created attachment 1370350 [details]
[PATCH v2] settings: clear unsaved flag on new settings-connection
Comment 7 Thomas Haller 2017-12-20 12:20:30 UTC 
(In reply to Beniamino Galvani from comment #6)
> Created attachment 1370350 [details]
> [PATCH v2] settings: clear unsaved flag on new settings-connection

Seem NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP_SAVED is not used anywhere. that is, it behaves exactly identical to NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP. 

Otherwise, the approach lgtm.
Comment 8 Beniamino Galvani 2017-12-20 12:32:21 UTC 
(In reply to Thomas Haller from comment #7)
> (In reply to Beniamino Galvani from comment #6)
> > Created attachment 1370350 [details]
> > [PATCH v2] settings: clear unsaved flag on new settings-connection
> 
> Seem NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP_SAVED is not used anywhere.
> that is, it behaves exactly identical to
> NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP. 

They behave differently:

nm_settings_connection_update():
...
 if (   replaced
     && persist_mode == NM_SETTINGS_CONNECTION_PERSIST_MODE_KEEP)
 	set_persist_mode (self, NM_SETTINGS_CONNECTION_PERSIST_MODE_UNSAVED);
 else
  	set_persist_mode (self, persist_mode);


which means that KEEP can set the unsaved flag if the connection changed while KEEP_SAVED cannot.
Comment 9 Thomas Haller 2017-12-20 14:05:42 UTC 
Right! LGTM then.
Comment 10 Beniamino Galvani 2017-12-20 14:43:28 UTC 
Applied to master:

https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=5fff928a6b746393e15487c348892b5ecaf8a416

and nm-1-10.
Comment 14 errata-xmlrpc 2018-04-10 13:35:58 UTC 
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/RHBA-2018:0778
Note You need to log in before you can comment on or make changes to this bug.