On Fri, 5 Feb 2016 02:20:06 -0500 Mark Mielke <mark.mie...@gmail.com> wrote:
> On Thu, Feb 4, 2016 at 7:49 AM, Flavio Leitner <f...@redhat.com> wrote: > > On Wed, 3 Feb 2016 22:01:46 -0500 Mark Mielke > > <mark.mie...@gmail.com> wrote: > >> > We need to split the issues: One is that enabling > >> > openvswitch.service causes it to run too soon. I think the > >> > proposed patch should resolve that (check journalctl -xe). > > >> The proposed patch doesn't seem to change anything. I checked > >> /var/log/messages and journalctl -xe. It has zero impact on the > >> order of the boot up. openvswitch-nonetwork.service still starts > >> too soon, before the physical interfaces have been probed and > >> recognized. In both cases, systemd has determined that > >> openvswitch-nonetwork.service is a dependency, and it starts it as > >> soon as syslog.target is reached (which is the constraint that > >> openvswitch-nonetwork.service defines). Adding > >> "After=network.service" to openvswitch.service does not affect > >> when openvswitch-nonetwork.service starts as > >> "After=network.target" is already more constraining than > >> "After=network.service"... > > > > It seems you're mixing the issues. > > > > openvswitch-nonetwork.service should not start by itself because it > > should not be enabled. It is considered internal to OVS > > initialization. > > I think you are misunderstanding me. I am describing not my own > thought process, but how systemd is actually implementing the systemd > service files that are used to define openvswitch-nonetwork.service > and openvswitch.service. > > You stated that you believed openvswitch.service should be a no-op. It > is not. Even with your patch, it is not. By having openvswitch.service > be enabled, it is causing openvswitch-nonetwork.service to be started > as soon as systemd can schedule it, which is After=syslog.target, and > in parallel to network.service, which is what causes it to run too > early. > > When it is disabled, everything works fine, because network.service > starts openvswitch-nonetwork.service on demand, after the physical > network interfaces have been probed and registered. > > It is openvswitch.service which is the problem that is causing > openvswitch-nonetwork.service to start too early. OK, now I see what you're saying. [...] > > The OVS initialization just fires up OVS daemons. It doesn't > > configure any ports or bridges because historically on Fedora that > > is what the network.service does, for each ifcfg- file available. > > > > Regarding to the second issue that we need to clean stale bonding > > ports from the DB to start from scratch I can provide a patch, but > > let's see about the first issue to avoid confusions and > > misunderstandings. > > To be clear, as I think you might be second-guessing my statements > with a presumption that I don't get it... > > Problem #1, that openvswitch-nonetwork.service starts too early if > openvswitch.service is on, actually causes a real problem, with > evidence in the logs. > > Problem #2, only happens for me if openvswitch-nonetwork.service > starts too early. If I turn openvswitch.service off *with or without* > your proposed alteration to After= to include network.service, then I > don't experience Problem #2. > > So, from my perspective... > > Problem #1 is a bug in how openvswitch.service is defined. There is a > misunderstanding here around how systemd operates, and there is no > correct patch on the table at the moment. The only fix here is to > disable openvswitch.service. Correct. Now that I see the real issue I can look more into it. > Problem #2 is mostly a work-around for Problem #1 in my case. However, > I can see how in *other* cases than mine, it could be a valuable > solution. For example, let us say that the physical interfaces for the > OVSBond changed. In this case, ifup-ovs should correctly reset the > bond to have the new configuration. Yes, the idea is to enforce the ifcfgs on every boot to make sure it is in a known and update state. Thanks, -- fbl _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
