As you mentionned, this issue is very hard to debug. It took me a while to figure out what was happening, and that this bug was causing my troubles. It prevents devstack + contrail-installer from working out of the box:

log files are present but not writeable, thus vnc_openstack will not fail to initialize, but logging will raise during exception handling in _resync_domains_projects_forever:

Traceback (most recent call last):
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/__init__.py", line 509, in _resync_domains_projects_forever
    retry = self._resync_all_projects()
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/__init__.py", line 427, in _resync_all_projects
    self._get_keystone_conn()
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/__init__.py", line 160, in _ksv2_get_conn
    insecure=self._insecure)
  File "/opt/stack/python-keystoneclient/keystoneclient/v2_0/client.py", line 147, in __init__
    self.authenticate()
  File "/opt/stack/python-keystoneclient/keystoneclient/utils.py", line 318, in inner
    return func(*args, **kwargs)
  File "/opt/stack/python-keystoneclient/keystoneclient/httpclient.py", line 425, in authenticate
    resp = self.get_raw_token_from_identity_service(**kwargs)
  File "/opt/stack/python-keystoneclient/keystoneclient/v2_0/client.py", line 190, in get_raw_token_from_identity_service
    "%s" % e)
AuthorizationFailure: Authorization Failed: Unable to establish connection to http://192.168.122.11:5000/v2.0/tokens


As a consequence self._ks will never be reset to None (self._ks = keystoneclient.openstack.common.apiclient.exceptions.AuthorizationFailure), and neutron api will stay stuck even if keystone becomes available.:

Traceback (most recent call last):
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/neutron_plugin_interface.py", line 146, in plugin_create_network
    net_info = cfgdb.network_create(network['resource'])
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/neutron_plugin_db.py", line 2067, in network_create
    net_obj = self._network_neutron_to_vnc(network_q, CREATE)
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/neutron_plugin_db.py", line 1107, in _network_neutron_to_vnc
    project_obj = self._project_read(proj_id=project_id)
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/neutron_plugin_db.py", line 203, in _project_read
    proj_obj = self._vnc_lib.project_read(id=proj_id, fq_name=fq_name)
  File "/usr/local/lib/python2.7/dist-packages/vnc_api/gen/vnc_api_client_gen.py", line 4990, in project_read
    content = self._request_server(rest.OP_GET, uri, query_params)
  File "/usr/local/lib/python2.7/dist-packages/vnc_api/vnc_api.py", line 366, in _request_server
    % (op, url, data, content))
NoIdError: Unknown id: Error: oper 2 url /project/9fc74e34-8b83-4484-b476-cde62cf447f9 body {'exclude_back_refs': True, 'exclude_children': True} response No project object found for id 9fc74e34-8b83-4484-b476-cde62cf447f9


Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/bottle.py", line 862, in _handle
    return route.call(**args)
  File "/usr/local/lib/python2.7/dist-packages/bottle.py", line 1729, in wrapper
    rv = callback(*a, **ka)
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/neutron_plugin_interface.py", line 221, in plugin_http_post_network
    return self.plugin_create_network(context, network)
  File "/opt/stack/contrail/controller/src/config/vnc_openstack/vnc_openstack/neutron_plugin_interface.py", line 150, in plugin_create_network
    raise e
NoIdError: Unknown id: Error: oper 2 url /project/9fc74e34-8b83-4484-b476-cde62cf447f9 body {'exclude_back_refs': True, 'exclude_children': True} response No project object found for id 9fc74e34-8b83-4484-b476-cde62cf447f9
127.0.0.1 - - [2014-10-17 00:00:44] "POST /neutron/network HTTP/1.1" 500 156 0.016092

Since it is staging for a while and quite annoying, i may propose a fix for this bug. While digging around this bug, it looks like that log permission is not the only issue, _ks is not very well managed, maybe should it be managed by_get_keystone_conn()?