how to deal with bridge device kernel module removal

[Jan Tluka]

Hi everyone,

I've come to a topic that we discussed some time ago but we did not
choose any path to follow since then.

Here's the case. I'm testing in a network with one virtual host that's running

on dom0 that acts both as the controller and a slave machine, too.
There's a bridge device on this multi-role machine involved in testing. The
bridge device gets configured but at the end of the test this device gets
cleaned up and bridge kernel module gets removed, too. This results in breaking
the libvirt's networking infrastructure for the guest and the libvirt's network
has to be reinitialized.

I know, not a typical use case but here's another more realistic.

A network with a bare-metal host hosting two guests (deployed in the <task>
part of the recipe) that are sending some data through dom0 to another
bare-metal host.

The solution to this is removing the _modulename from the bridge device code.

What's your opinion on this?

-Jan

[Ondrej Lichtner]

Hi,

from my point of view lnst-slave shoudln't remove any modules, or in
fact clean up services/daemons/anything that has a chance of breaking
configuration that was not done by lnst-slave.

> From what I can recall this was roughly what we have agreed on
previously and I still support this. I can make a patch for this when we
have fully agreed on this.

Removing the _modulename however is not the way I would go, the reason
being lnst-slave might want to modprobe the module enable bridge
configuration. The policy would therefore be add what we need, but
remove only what can't break anything else even if the module was
modprobed by lnst-slave.

-Ondrej

On Thu, Nov 07, 2013 at 06:10:58PM +0100, Jan Tluka wrote:
>  Hi everyone,
>  
>  I've come to a topic that we discussed some time ago but we did not
>  choose any path to follow since then.
>  
>  Here's the case. I'm testing in a network with one virtual host that's
> running 
>  on dom0 that acts both as the controller and a slave machine, too.
>  There's a bridge device on this multi-role machine involved in testing. The
>  bridge device gets configured but at the end of the test this device gets
>  cleaned up and bridge kernel module gets removed, too. This results in breaking
>  the libvirt's networking infrastructure for the guest and the libvirt's network
>  has to be reinitialized.
>  
>  I know, not a typical use case but here's another more realistic.
>  
>  A network with a bare-metal host hosting two guests (deployed in the <task>
>  part of the recipe) that are sending some data through dom0 to another
>  bare-metal host.
>  
>  The solution to this is removing the _modulename from the bridge device code.
>  
>  What's your opinion on this?
>  
>  -Jan
>  _______________________________________________
>  LNST-developers mailing list
>  LNST-developers(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/lnst-developers

[Jan Tluka]

Fri, Nov 08, 2013 at 08:34:02AM CET, olichtne(a)redhat.com wrote:
> Hi,
>
> from my point of view lnst-slave shoudln't remove any modules, or in
> fact clean up services/daemons/anything that has a chance of breaking
> configuration that was not done by lnst-slave.
>
> From what I can recall this was roughly what we have agreed on
> previously and I still support this. I can make a patch for this when we
> have fully agreed on this.
>
> Removing the _modulename however is not the way I would go, the reason
> being lnst-slave might want to modprobe the module enable bridge
> configuration. The policy would therefore be add what we need, but
> remove only what can't break anything else even if the module was
> modprobed by lnst-slave. 
You're right, I forgot the initialization part. On the other hand I'm
not really sure about the team driver. Currently the team driver module
loading is disabled with _moduleload=False. I guess the team driver
handles loading of required modules by itself.

Jiri can you confirm the above? And another question is whether we can
kill the teamd daemon having the team drivers loaded? Does it affect
anything if further tests involve team?

-Jan

> -Ondrej
>
> On Thu, Nov 07, 2013 at 06:10:58PM +0100, Jan Tluka wrote:
> > Hi everyone,
> > 
> > I've come to a topic that we discussed some time ago but we did not
> > choose any path to follow since then.
> > 
> > Here's the case. I'm testing in a network with one virtual host that's
> running 
> > on dom0 that acts both as the controller and a slave machine, too.
> > There's a bridge device on this multi-role machine involved in testing. The
> > bridge device gets configured but at the end of the test this device gets
> > cleaned up and bridge kernel module gets removed, too. This results in breaking
> > the libvirt's networking infrastructure for the guest and the libvirt's
> network
> > has to be reinitialized.
> > 
> > I know, not a typical use case but here's another more realistic.
> > 
> > A network with a bare-metal host hosting two guests (deployed in the <task>
> > part of the recipe) that are sending some data through dom0 to another
> > bare-metal host.
> > 
> > The solution to this is removing the _modulename from the bridge device code.
> > 
> > What's your opinion on this?
> > 
> > -Jan
> > _______________________________________________
> > LNST-developers mailing list
> > LNST-developers(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/lnst-developers

[Jiri Pirko]

Fri, Nov 08, 2013 at 09:31:05AM CET, jtluka(a)redhat.com wrote:
> Fri, Nov 08, 2013 at 08:34:02AM CET, olichtne(a)redhat.com wrote:
> >Hi,
> >
> >from my point of view lnst-slave shoudln't remove any modules, or in
> >fact clean up services/daemons/anything that has a chance of breaking
> >configuration that was not done by lnst-slave.
> >
> >From what I can recall this was roughly what we have agreed on
> >previously and I still support this. I can make a patch for this when we
> >have fully agreed on this.
> >
> >Removing the _modulename however is not the way I would go, the reason
> >being lnst-slave might want to modprobe the module enable bridge
> >configuration. The policy would therefore be add what we need, but
> >remove only what can't break anything else even if the module was
> >modprobed by lnst-slave.
>
> You're right, I forgot the initialization part. On the other hand I'm
> not really sure about the team driver. Currently the team driver module
> loading is disabled with _moduleload=False. I guess the team driver
> handles loading of required modules by itself. 
when you run teamd, it will load the driver itself (via Netlink iface)

> Jiri can you confirm the above? And another question is whether we can
> kill the teamd daemon having the team drivers loaded? Does it affect
> anything if further tests involve team? 
when you kill the teamd with sigint for example, it will remove the
driver instance (netdev).


> -Jan
>
> >-Ondrej
> >
> >On Thu, Nov 07, 2013 at 06:10:58PM +0100, Jan Tluka wrote:
> >> Hi everyone,
> >> 
> >> I've come to a topic that we discussed some time ago but we did not
> >> choose any path to follow since then.
> >> 
> >> Here's the case. I'm testing in a network with one virtual host
> that's running 
> >> on dom0 that acts both as the controller and a slave machine, too.
> >> There's a bridge device on this multi-role machine involved in testing. The
> >> bridge device gets configured but at the end of the test this device gets
> >> cleaned up and bridge kernel module gets removed, too. This results in breaking
> >> the libvirt's networking infrastructure for the guest and the libvirt's
> network
> >> has to be reinitialized.
> >> 
> >> I know, not a typical use case but here's another more realistic.
> >> 
> >> A network with a bare-metal host hosting two guests (deployed in the
> <task>
> >> part of the recipe) that are sending some data through dom0 to another
> >> bare-metal host.
> >> 
> >> The solution to this is removing the _modulename from the bridge device code.
> >> 
> >> What's your opinion on this?
> >> 
> >> -Jan
> >> _______________________________________________
> >> LNST-developers mailing list
> >> LNST-developers(a)lists.fedorahosted.org
> >> https://lists.fedorahosted.org/mailman/listinfo/lnst-developers
> _______________________________________________
> LNST-developers mailing list
> LNST-developers(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/lnst-developers