Adding syslog support in contrail-log

Change-Id: I09f6620abed6c2013d6371d16fe218799ed45a33
Enable agent tests for CI (non flaky).
Remove build error for flaky test.

Change-Id: I88b3bbf94fd05d3c2953b6218cb426ae29d9fb4b
Fix concurrency issue in lifetime manager.

Some unit tests failed during TearDown when trying to access a
virtual method for a partially destroyed object.  One thread was
in the process of removing a dependent object's LifetimeRef from
the parent LifetimeActor's dependency list. This was happening
via the destructor for the dependent object.  At the same time,
the main thread was in the process of propagating Delete from the
parent LifetimeActor to it's dependents.

Fix is to perform propagation of delete from the LifetimeManager
task rather than doing it inline from the Delete method.  Notice
that this splits up delete propagation into multiple steps.  An
actor propagates delete to it's immediate children.  If a child
has a LifetimeActor it gets added to the LifetimeManager queue.
Further propagation happens when the child LifetimeActor itself
is processed from the queue.

This change broke some tests which expected that the delete is
propagated inline.  As an example, if the MemebershipManager is
stopped and has requests to process, and a routing instance is
deleted, the tables for the instance don't get marked deleted
as BgpServer::IsReadyForDeletion doesn't let the LifetimeManager
task process the queue.

Fixed this issue by adding a MayDestroy method to LifetimeManager.
Instead of not processing the LifetimeManager queue at all, we
now process the first item on the queue, invoking Shutdown and
PropagateDelete if needed, and then put the LifetimeActor back on
the queue if MayDestroy returns false.

Defined a BgpLifetimeManager class whose MayDestroy method calls
BgpServer::IsReadyForDeletion.

Change-Id: I6b5688f5362fbf5591c84c78f56e4a682cb95587
Closes-Bug: #1349980
The issue is when we process rabbitmq message for instance ip delete, we
access the virtual network. In case of the problem, the VN is deleted by
this time. Hence the exception is thrown in "dbe_delete_notification" function of InstanceIpServer.
Fix:
1. ip_free_notify should only free the ip from the subnet it already knows.
2. Even if the "dbe_xxx_notification" fails, inform the if map server.  This is to ensure that cassandra and if map are in sync.
3. Add logging for "dbe_oper_subscribe" exceptions. The error is critical and hard to debug without this error log.

Change-Id: I1851a3b6a3efd96f632db16a1a8e6ea23a1feda0
Raises the correct exception when adding interface to subnet

This fix changes the exception raised when trying to
add a router interface on a subnet while the
router already has a interface on that subnet.

Change-Id: Ic6034f1c1badf21ff6fafac0441de43857fd0e9f
Fixes some NoIdError exceptions that were not catched

Fixes some crashes due to some NoIdError not catched.

Change-Id: Id9bf861221fc8dd4b428179222100dfb5fa49648
Closes-bug: #1351081
status_type as a string instead of the numerical value

Report the textual value a of netns_command status_type
instead of the numerical value in the introspec webui.

Change-Id: I9248773ec0810a49aeb933a5e6e355642639f3b0
(cherry picked from commit be25e694ad8d274f3fb627a16ffb0eb990a40326)
Restore enqueueing a route add/change/delete request should be done in default vrf.

Change-Id: Ia4dd8479f6b9116455c7d4840ad7da3041edeedf
Merge "Closes-Bug: #1349980 The issue is when we process rabbitmq message for instance ip delete, we access the virtual network. In case of the problem, the VN is deleted by this time. Hence the exception is thrown in "dbe_delete_notification" function of InstanceIpServer. Fix: 1. ip_free_notify should only free the ip from the subnet it already knows. 2. Even if the "dbe_xxx_notification" fails, inform the if map server.  This is to ensure that cassandra and if map are in sync. 3. Add logging for "dbe_oper_subscribe" exceptions. The error is critical and hard to debug without this error log."
Merge "Restore enqueueing a route add/change/delete request should be done in default vrf."
Merge "Fix concurrency issue in lifetime manager."
[SNAT SVC monitor] Improve scheduling on VRouter

Add a scheduler base class.
Check if the VRouter is up and running before selected it for running a
network namespace of the SI.
Destroy and recreate the network namespace if the VRouter goes down.
This patch request the vrouter uve on the analytics API, if it receive a
HTTP 200 code, the VRouter is considered up and down otherwise.

Change-Id: Ie5c933ee3bd0a7cdac076289b4e9030db8833c82
Merge "status_type as a string instead of the numerical value"
Merge "Fixes some NoIdError exceptions that were not catched"
Merge "[SNAT SVC monitor] Improve scheduling on VRouter"
Cleanup of connection info:
1. Make consistent the UVE names for connection info
2. Rename process state to process info and move to NodeStatus,
   corresponding node manager changes
3. Namespace for connection info to avoid conflicts
4. Rename connection_info.sandesh to process_info.sandesh
5. Extract common function to updated process state into lib

Change-Id: I52f3c3faa814c6459d3b2d2958fe9a9c56f29841
VM fq_name should not contain ':' since it is a top level object.
':' is used as a delimiter and hence backend parsing breaks for
VM. Plan is to generate an error from backend for such cases and
prevent the write from going through.

Change-Id: Id1c9a51d2ce5f9c8f71e99a724c5893589abcd5b
Use the correct task instance in cdbq cleanup, initialization and
dequeue tasks to avoid cdbq being deleted when dequeue task is
running

Closes-Bug: #1349731
Change-Id: Ia31ba91f46d3b48c697ccf4c937516ac1642b968
Merge "Use the correct task instance in cdbq cleanup, initialization and dequeue tasks to avoid cdbq being deleted when dequeue task is running"
Closes-Bug: #1351398
The key for the config object table was reversed because of the way sandesh object log was
defined. Fixed that.

The api-server does not follow uve semantics, hence removing the logging of virtual-network
and virtual-machine UVEs from the api-server.

Change-Id: I4538da3395665ef14ee4a939f1ea4e31502563e5