On Wed, Jan 18, 2017 at 09:57:00AM +0100, Eelco Chaudron wrote: > On 17/01/17 20:12, Ben Pfaff wrote: > >On Tue, Jan 17, 2017 at 12:10:59PM -0200, Flavio Leitner wrote: > >>On Tue, 17 Jan 2017 09:34:19 +0100 > >>Eelco Chaudron <[email protected]> wrote: > >> > >>>Currently OVS does not distinguish between a bond slave being operational > >>>disabled, i.e. link being down, and administratively disabled. > >>> > >>>Take the example where the administrator disabled a link in a bond, > >>>"ovs-appctl bond/disable-slave bond0 enp129s0f0", it's automatically > >>>enabled again due to the fact the link is up. > >>> > >>>I would like to change this behavior such that when disabled trough appctl > >>>the slave is no longer used until explicitly enabled again via appctl. > >>Eelco and I discussed this off list and I agree that this sounds like > >>a bug. The slave should not be used if the admin has disabled it > >>regardless of its link state. > >The behavior matches the documentation: > > > > bond/enable-slave port slave > > bond/disable-slave port slave > > Enables (or disables) slave on the given bond port, skipping > > any > > updelay (or downdelay). > > > > This setting is not permanent: it persists only until the > > car‐ > > rier status of slave changes. > > So to administratively disable a link, you should either force the link to > be down (and don't forget after system reboot), or remove the slave from the > bond? If so, no re-work is needed here.
I guess that I would rather say that OVS does not currently have a concept of a slave being administratively disabled while it is part of a bond. If it's useful to have such a concept, then I'm open to the discussion. Part of the discussion needs to be a rationale for why this new concept is valuable, given the other possibilities that you mention. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
