Comment # 28 on bug 911562 from Pawel Wieczorkiewicz

(In reply to Tom Burkart from comment #27)
> (In reply to Pawel Wieczorkiewicz from comment #26)
> > But before please ensure you have tried information provided in comment#4
> > and comment#12 of this bug with wicked 0.6.18.
> 
> Turning on nanny does "fix" the problem.
> But why is this required for a "static IP" setup?  The reality is that in
> this case nanny needs to be enabled by default on systems where there is any
> possibility of loss of link during boot.  This covers >80% of systems.  To
> me that is a serious flaw.

Have you used LINK_READY_WAIT variable with your ifcfg config? Have you set
this variable to the value smaller than value of WAIT_FOR_INTERFACES from
/etc/sysconfig/network/config file?
If you haven't, the standalone wicked client call will timeout after
$WAIT_FOR_INTERFACES seconds waiting for the link to come up. Thus nanny needs
to be used, which is a client daemon dealing with hotplug scenarios like yours.

See this excerpt from ifcfg(5):

LINK_READY_WAIT
    This variable configures how long to wait for the link detection (by the
kernel / network card driver) in seconds.  Default is 0, causing to not wait at
all if link is not required or wait infinitely when link is required, so nanny
can continue with the setup when the cable gets connected to the network card
after a while.  Otherwise wicked will wait until the specified number of
seconds and continue with further steps if link is not required or fail and
stop further steps if nanny is not used (see use-nanny in wicked-config(5)). 
Note, that an ifup call has it's own, independent timeout, which is limiting
the maximal time ifup waits before it has to report (see global network/config
WAIT_FOR_INTERFACES variable).