Bug 1311469 - team device autostarts even with connection.autoconnect: no
team device autostarts even with connection.autoconnect: no
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager (Show other bugs)
7.2
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Rashid Khan
Desktop QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-24 05:25 EST by lejeczek
Modified: 2016-02-26 07:06 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-25 12:21:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description lejeczek 2016-02-24 05:25:11 EST
Description of problem:

set it to no:

connection.id:                          10.5.6.100
connection.uuid:                        ff5e970c-be1f-4b6d-9235-1197b3a4ec7a
connection.interface-name:              nm-team
connection.type:                        team
connection.autoconnect:                 no
connection.autoconnect-priority:        0
connection.timestamp:                   1456309115
connection.read-only:                   no

yes still device will be auto started.

Version-Release number of selected component (if applicable):

NetworkManager-1.0.6-27.el7.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 2 Thomas Haller 2016-02-24 05:46:21 EST
do you have a slave-device that is autoconnect=yes?

Activating a slave obviously brings up the master too. Same for auto-activating a slave.
Comment 3 lejeczek 2016-02-24 06:02:17 EST
and do not see how it's obvious - they are slaves, right?
If I remember correctly I had to change master

connection.autoconnect-slaves:          1 (yes)

from default(-1) because device would not initialize.
And if remember correctly then that master ordered the slaves on this occasion, must have changed their autoconnect - if I remember correctly, but probably very easy for devs to reproduce - if true then it's confusing & inconsistent.
Comment 4 Thomas Haller 2016-02-24 06:12:09 EST
(In reply to lejeczek from comment #3)
> and do not see how it's obvious - they are slaves, right?

A slave cannot be activated without a master.



> If I remember correctly I had to change master
> 
> connection.autoconnect-slaves:          1 (yes)
> 
> from default(-1) because device would not initialize.

connection.autoconnect-slaves is a property of the master connection, and indicates that when the master activates, it will also activate the slaves.

The question is, whether you have any slave connections with "connection.autoconnect yes".

> And if remember correctly then that master ordered the slaves on this
> occasion, must have changed their autoconnect - if I remember correctly, but
> probably very easy for devs to reproduce - if true then it's confusing &
> inconsistent.

What do you mean is confusing and inconsistent? Modifying connection.autoconnect-slaves does not "change [the slaves] autoconnect", as you can see via `nmcli connection show $SLAVE_CONNECTION`.
Comment 5 lejeczek 2016-02-25 10:04:00 EST
All I'm trying to say, to suggest is that slaves should (only in this context naturally) behave as ones, which is do what master says.
Comment 6 Thomas Haller 2016-02-25 11:33:50 EST
(In reply to lejeczek from comment #5)
> All I'm trying to say, to suggest is that slaves should (only in this
> context naturally) behave as ones, which is do what master says.

Sorry, I don't understand what you mean.


The point is, that the issue that you describe (team device autostarts even with connection.autoconnect: no) could be explained by the configuration of your slave.

Please ensure that the "connection.autoconnect" setting of all your slave connections is "no". Can you verify that?

Otherwise, please also attach `journalctl -b 0 -u NetworkManager` of your last boot.


Thank you.
Comment 7 lejeczek 2016-02-25 11:52:41 EST
if master says "autoconnect no" then slave should obey, should not matter what they have to say.
Like you said "connection.autoconnect-slaves is a property of the master connection, and indicates that when the master activates, it will also activate the slaves." and this logic (given that connection.autoconnect-slaves:          -1 (default) , I don't need to consider other, user set values for now) should extend and it all should be govern my master's autoconnect - if master does autoconnect Not so should Not the slaves.
But it's ok, no point debating it over, lets close this report.
Comment 8 Thomas Haller 2016-02-25 12:21:43 EST
(In reply to lejeczek from comment #7)
> if master says "autoconnect no" then slave should obey, should not matter
> what they have to say.
> Like you said "connection.autoconnect-slaves is a property of the master
> connection, and indicates that when the master activates, it will also
> activate the slaves." and this logic (given that
> connection.autoconnect-slaves:          -1 (default) , I don't need to
> consider other, user set values for now) should extend and it all should be
> govern my master's autoconnect - if master does autoconnect Not so should
> Not the slaves.
> But it's ok, no point debating it over, lets close this report.


A slave cannot connect without also activating the master. Activating a slave always activates the master too -- regardless, whether the slave was activated by explicit user-decision or whether the slave auto-activated.

autoconnect=no on the master does not mean that slaves are forbidden to autoconnect.
That does not follow from "connection.autoconnect-slaves is a property ..."


According to your expectation, the connection.autoconnect property of the slave would be always overruled by the master's configuration.
With the current setup you could have:

   eth0
     connection.autoconnect=yes
   eth1
     connection.autoconnect=no
   master0
     connection.autoconnect=yes

and at startup only eth0 gets enslaved. You cannot achieve the same with your interpretation.


Also, connection.autoconnect-slaves is still useful:

   eth0
     connection.autoconnect=no
   eth1
     connection.autoconnect=no
   master0
     connection.autoconnect=no
     connection.autoconnect-slaves=yes

now, nothing gets activated at boot, but once you activate the master, it's slaves are activated too.
Comment 9 lejeczek 2016-02-25 12:35:29 EST
I understand what your are saying, I see how it behaves, it's fine. I thought wrong, I only think it looks, sounds silly - when master autoconnect=no yet gets up only because one missed a slave, yes should be overruled in my mind.
thanks.

Note You need to log in before you can comment on or make changes to this bug.