Support dynamic change of tunnel encapsulation - handle NH change for existing VM in case of encap change
Cosmetic changes - rename of variable and addition of logs/comments
Add X-TENANT-ID header to the metadata request sent to nova api
Add agent route walker and move encap change walk to use the same
fix test case
merge and conflict resolution with upstream
Unit tests to verify relative_time were not calling the parse_time
function in query.cc as expected. Changing the way we post query
made the the function to be called properly. Also the UT has been
added to check OBJECT_VALUE_TABLE.
Code changes:
Query class has been moved from perftest.py to analytics_fixture.py
as it is used elsewhere and util would be a proper place.
Instead of query query_json objects are called so that passed parameters
are not interpreted by the util scripts before calling the actual functions.
Test:
Coverage report shows the parse_time function being referred in query.cc
Merge remote branch 'upstream/master'

Conflicts:
	src/vnsw/agent/oper/operdb_init.cc
Get project uuid from Nova vif driver and use that while proxying for metadata
Merge pull request #242 from ashoksr/master

UT for VN and VM UVE
Use UuidToString instead of using stringstream
Merge pull request #239 from Juniper/arvind-coverage

Unit tests to verify relative_time were not calling the parse_time
Review comments
All boost async operations need to occur in the context of the same task i.e.
the task that is executing run(). In our case, its the main task.
io_service.post() guarantees that the handler will only be called in a thread
in which the run(), run_one(), poll() or poll_one() member functions is
currently being invoked. But, there are no guarantees wrt to ordering.
Using strand.post() guarantees the thread and also has some ordering
guarantees. In our case, we have the main-task and sm-task that are competing.
Intuitively, it makes sense to enforce ordering of callbacks since the events
triggering the callbacks are ordered and this is a state-machine where the same
event in a different state could cause issues. So, we will use strand.post().
Also, adding a small macro to check if we are running in the context of the
main-task and using it to check that we are in the right context while
executing the boost-async calls.
Flow entry handling modification to handle NH change of a route because of tunnel encap change
Merge pull request #190 from manishsing/master

Support dynamic change of tunnel encapsulation - handle NH change for ex...
Merge pull request #232 from haripk/master

Add X-TENANT-ID header to the metadata request sent to nova api
Commit to github to Handle 503 error due to Discovery Server not UP
Fix cut-paste error in definition of CHECK_CONCURRENCY_MAIN_THR
Merge pull request #243 from Juniper/tkarwa_script

All boost async operations need to occur in the context of the same task...