[Starlingx-discuss] Questions about patch 87a8c625 upstreaming

[Le, Huifeng]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.starlingx.io/pipermail/starlingx-discuss/attachments/20181205/532d2548/attachment.html>