[cmaster-next] stable/2.0 / initial delay before BGP availability through vty

[Philippe Guibert]

Hi Donald,

I have 2 questions/remarks.

1) Is there any specific reason why having kept the delay just after
starting BGP daemon.
Even with disabling zebra in configure, it takes quite some time.

The root cause is related to:
lib: Allow zclient do-over of connect on initial attempt

Is there any reason to keep the mecanism like that ?
Side effect of this is if you just execute bgp daemon and expect it to
be available for configuration, either from vty ( or in a near-future
basis capnproto), then the locked thread mecanism makes that it is not
possible to immediately configure daemon.
I would revert the commit. No ?


2) About this trace
BGP: SLOW THREAD: task zclient_connect

As this trace may happen more than once, is it necessary to add by default that
I would put a conditionate to that trace.

Regards,

Philippe

===================================

/sbin/bgpd
2016/12/08 17:33:55 BGP: BGPd 2.0-rc0 starting: vty at 2605, bgp@<all>:179
2016/12/08 17:33:55 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:33:56 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:33:57 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:33:58 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:33:59 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:00 BGP: SLOW THREAD: task zclient_connect
(7fa0e93c0cbc) ran for 5002ms (cpu time 0ms)
2016/12/08 17:34:00 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:01 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:02 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:03 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:04 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:05 BGP: zclient_socket_un connect failure: 2
2016/12/08 17:34:05 BGP: SLOW THREAD: task zclient_connect
(7fa0e93c0cbc) ran for 5000ms (cpu time 0ms)

=> Just at this point, VTY access OK