From: Ido Schimmel
Date: Tue, 27 Feb 2018 17:38:08 +0200
> Use extack inside team's enslavement function and also propagate it to
> the netdevice notifier to allow enslaved ports to report the failure
> reason. Example:
>
> $ teamd -t team0 -d -c '{"runner": {"name": "lacp"}}'
> $ ip link set de
From: Jiri Pirko
Date: Wed, 28 Feb 2018 08:12:41 +0100
> Wed, Feb 28, 2018 at 12:49:59AM CET, kubak...@wp.pl wrote:
>>On Tue, 27 Feb 2018 22:22:12 +0200, Ido Schimmel wrote:
>>> > If so, for how long? They should certainly be removed eventually. How
>>> > do we ensure we don't forget?
>>> >
>>>
Wed, Feb 28, 2018 at 09:58:03AM CET, jb...@redhat.com wrote:
>On Wed, 28 Feb 2018 08:12:41 +0100, Jiri Pirko wrote:
>> Yeah, or if you have an older iproute2 package. I would keep the existing
>> dmesg msgs for now. In the future, when everyone is used to exacks, then
>> we can remove them.
>
>How
On Wed, 28 Feb 2018 08:12:41 +0100, Jiri Pirko wrote:
> Yeah, or if you have an older iproute2 package. I would keep the existing
> dmesg msgs for now. In the future, when everyone is used to exacks, then
> we can remove them.
How do we ensure that this will actually happen in the future? Usually,
> >> > If so, for how long? They should certainly be removed eventually. How
> >> > do we ensure we don't forget?
> >> >
> >> > Seems to me it would be better to remove them right now.
> >>
> >> I can do that unless someone objects.
> >
> >I don't object, but FWIW keep in mind extack errors don't s
Wed, Feb 28, 2018 at 12:49:59AM CET, kubak...@wp.pl wrote:
>On Tue, 27 Feb 2018 22:22:12 +0200, Ido Schimmel wrote:
>> > If so, for how long? They should certainly be removed eventually. How
>> > do we ensure we don't forget?
>> >
>> > Seems to me it would be better to remove them right now.
>>
On Tue, 27 Feb 2018 22:22:12 +0200, Ido Schimmel wrote:
> > If so, for how long? They should certainly be removed eventually. How
> > do we ensure we don't forget?
> >
> > Seems to me it would be better to remove them right now.
>
> I can do that unless someone objects.
I don't object, but FWI
On Tue, Feb 27, 2018 at 08:42:35PM +0100, Jiri Benc wrote:
> On Tue, 27 Feb 2018 17:38:08 +0200, Ido Schimmel wrote:
> > if (port_dev->flags & IFF_LOOPBACK) {
> > + NL_SET_ERR_MSG(extack, "Loopback device can't be added as a
> > team port");
> > netdev_err(dev, "Device %s
On Tue, 27 Feb 2018 17:38:08 +0200, Ido Schimmel wrote:
> if (port_dev->flags & IFF_LOOPBACK) {
> + NL_SET_ERR_MSG(extack, "Loopback device can't be added as a
> team port");
> netdev_err(dev, "Device %s is loopback device. Loopback devices
> can't be added as a te
On 2/27/18 8:38 AM, Ido Schimmel wrote:
> Use extack inside team's enslavement function and also propagate it to
> the netdevice notifier to allow enslaved ports to report the failure
> reason. Example:
>
> $ teamd -t team0 -d -c '{"runner": {"name": "lacp"}}'
> $ ip link set dev lo master team0
>
Use extack inside team's enslavement function and also propagate it to
the netdevice notifier to allow enslaved ports to report the failure
reason. Example:
$ teamd -t team0 -d -c '{"runner": {"name": "lacp"}}'
$ ip link set dev lo master team0
Error: Loopback device can't be added as a team port.
11 matches
Mail list logo