See inline From: "Le, Huifeng" <huifeng.le@intel.com> Date: Friday, December 7, 2018 at 4:11 AM To: "Peters, Matt" <Matt.Peters@windriver.com> Cc: "starlingx-discuss@lists.starlingx.io" <starlingx-discuss@lists.starlingx.io> Subject: RE: Questions about patch 87a8c625 upstreaming Matt, Thanks much for the clarification! Sorry for more questions: * Current metadata proxy is managed by l3 agent or dhcp agent or both (e.g. there may be 3 haproxy processes co-exists in an environment with 1 route and 2 network). The STX patch is applied for dhcp agent now, Does it also need the capability for l3 agent to stop the haproxy (managed by l3 agent) when stopped? MP> Yes. This was not included in the original patch because the original seed code did not use the default L3 agent. * The patch has a side effect of disabling the metadata query capability (from vm instance) when dhcp agent stop, suppose this is expected behavior, right? MP> Yes. It needs to be temporarily stopped while it is patched. Best Regards, Le, Huifeng From: Peters, Matt [mailto:Matt.Peters@windriver.com] Sent: Thursday, December 6, 2018 11:11 PM To: Le, Huifeng <huifeng.le@intel.com> Cc: starlingx-discuss@lists.starlingx.io Subject: Re: Questions about patch 87a8c625 upstreaming Hello Huifeng, I believe the use-case was having the ability to restart the metadata proxy in order to provide the ability to patch the software without a reboot. Therefore, in order to restart and/or reconfigure the metadata proxies that are managed by the DHCP agent, then they needed to be restarted when the agent was restarted since there was no direct way to restart the individual proxies managed by that service. The DHCP agent will automatically configure and launch the metadata proxy if there are no virtual routers currently serving that network. This is controlled by the parameter enable_isolated_metadata and is configured to be True by default for StarlingX. The force_metadata option can be used to always have the DHCP agent configure the metadata access but is not enabled by default (as you indicated). -Matt From: "Le, Huifeng" <huifeng.le@intel.com<mailto:huifeng.le@intel.com>> Date: Wednesday, December 5, 2018 at 4:20 AM To: "Peters, Matt" <Matt.Peters@windriver.com<mailto:Matt.Peters@windriver.com>> Cc: "starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>" <starlingx-discuss@lists.starlingx.io<mailto:starlingx-discuss@lists.starlingx.io>> Subject: Questions about patch 87a8c625 upstreaming Matt, I am looking at patch #87a8c625 (US86444: patching scripts for neutron processes) which includes 2 parts, could you please help to clarify below question? * Script to support neutron service restart: This is STX special script and no need for upstream * Metadata-proxy service lifecycle management: close metadata proxy (e.g. haproxy) process (if it is managed by dhcp client) when neutron-dhcp-agent stopped To my understanding, metadata proxy (e.g. haproxy) provides support for VM instance to query its metadata information from Neutron which is in data-path plane, neutron-dhcp-agent is responsible for configuring dhcp process (e.g. dnsmasq) or metadata proxy process which is lie in control-path plane. So it seems by design: whether the metadata-proxy process is alive is determined by the network/port status change instead of whether dhcp agent alive. Are there any special use cases which requires to stop metadata proxy process when dhcp agent stopped? In my test: * if metadata proxy is managed by l3 agent (default setting) Stopping(/Restarting) l3 agent will not stop(/restart) haproxy process and clear iptables rule, router can still work (in data path) and metadata information can still be queried inside VM instance * if metadata proxy is managed by dhcp agent (set “force_metadata = true” in /etc/neutron/dhcp_agent.ini) Stopping(/Restarting) dhcp agent will not stop(/restart) dnsmasq process and haproxy process, dhcp server can still work (in data path) and metadata information can still be queried inside VM instance. If applying the patch, Stopping dhcp agent will make the metadata query within VM instance fail while the DHCP server can still work (or does it also need to be stopped?) and metadata bridge information (e.g. 169.254.169.254/16) is also valid in dhcp interface, does it expected behavior? Thanks much! Best Regards, Le, Huifeng