Change the default value of metadata_on_demand from True to False
because the following reasons:
1. Due to current dnsmasq bug, new VMs on a DHCP-enabled subnet may still
get the metadata route to DHCP port via dnsmasq DHCP options. Once the
bug is fixed, new VMs will get the metadata route to router port via
dnsmasq DHCP options. If we have metadata_on_demand=False and
force_metadata=False, we can always have internal metadata network
ready, which can handle the metadata requests routed to the router
port if the dnsmasq bug is fixed.
2. According to current DHCP agent implementation, if DHCP agent is
restarted, it will try to restart all metadata proxies. But it will
skip the metadata proxy for a network that has any subnet attached
to a router. Instead, DHCP agent will start a metadata-proxy for the
router. If old metadata proxy processes are still running, then it
should be fine. But consider the case when a openstack network node
is restarted, then all old processes are gone. Thus DHCP agent will
not start those metadata proxies for networks with attached router.
This means any VM that has routing table containing a metadata route
to the DHCP port will fail to reach metadata service because the
corresponding metadata proxy that handle 169.254.169.254:80 is not
running.
3. When (2) happens, if we have force_metadata=True, dnsmasq will
provide metadata route to DHCP port for any new VM on a DHCP-enabled
and router-attached subnet. So those VMs will fail to reach metadata
service.
4. When (2) happens, if we have force_metadata=False, dnsmasq will
provide metadata route to router port for any new VM on a DHCP-enabled
and router-attached subnet. If metadata_on_demand=False, the
pre-created internal metadata network can forward the metadata
requests from those VMs. But if metadata_on_demand=True, the internal
metadata network is not created because the router is attached to a
DHCP-enabled subnet. Thus the router can not route those metadata
requests.
Also fix metadata tags used in NSX|V3 unit tests.
Change-Id: I6d39dffa365f172ad24530ee938b5af3483a7a18
4a419f3790