Comment 18 for bug 1524916

Revision history for this message
Miguel Angel Ajo (mangelajo) wrote :

I wonder how do the OVN guys plan to offer metadata in a native l3 implementation.

After thinking of this issue for months, I cannot find a decent way to do this using existing tools, leveraging openflow, or iptables without the risk of exposing the host network to the tenant.

The most reasonable way to tackle this and help scalability IMHO is writing a tiny daemon in C/C++, (I estimate <1 month or so for an experienced C developer), it's just a matter of taking HTTP requests, augmenting them with X-Neutron-Router-ID or X-Neutron-Network-ID and forwarding to the unix socket & back while translating error responses. [1]

I'd be glad to take on that if my managers ( ;-) ) wanted to devote some of my time to it, and the community was happy to accept a C version of the metadata agent in tree (I'd prefer to avoid a separate project/repo for something of a magnitude of <1000LOC)

I have like >10 years of C/C++ writing experience, and I know about security and how modern exploits work, so my code (or code under my review) would be likely to pass any audit.

@russellb, @amuller, @* any thoughts on this?.

Another alternative could be go, as long as we can make our executable dynamically linked (opposed to the statically linked Go standard which would again hurt RSS/PSS memory ratios).

[1] https://github.com/openstack/neutron/blob/master/neutron/agent/metadata/namespace_proxy.py