<div dir="ltr">It would be interesting for this to be built in a way where other endpoints could be added to the list that have extra headers added to them.<div><br></div><div>For example, we could end up with something quite similar to EC2 IAMS if we could add headers on the way through for requests to OpenStack endpoints.</div><div><br></div><div>Do you think the design your proposing will be extensible like that?</div><div><br></div><div>Thanks,</div><div>Michael</div><div><br></div><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 5, 2017 at 10:07 PM, Daniel Alvarez Sanchez <span dir="ltr"><<a href="mailto:dalvarez@redhat.com" target="_blank">dalvarez@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">Hi folks,<div><br></div><div>Now that it looks like the metadata proposal is more refined [0], I'd like</div><div>to get some feedback from you on the driver implementation.</div><div><br></div><div>The ovn-metadata-agent in networking-ovn will be responsible for</div><div>creating the namespaces, spawning haproxies and so on. But also,</div><div>it must implement most of the "old" neutron-metadata-agent functionality</div><div>which listens on a UNIX socket and receives requests from haproxy,</div><div>adds some headers and forwards them to Nova. This means that we can</div><div>import/reuse big part of neutron code.</div><div><br></div><div>I wonder what you guys think about depending on neutron tree for the</div><div>agent implementation despite we can benefit from a lot of code reuse.</div><div>On the other hand, if we want to get rid of this dependency, we could</div><div>probably write the agent "from scratch" in C (what about having C</div><div>code in the networking-ovn repo?) and, at the same time, it should</div><div>buy us a performance boost (probably not very noticeable since it'll</div><div>respond to requests from local VMs involving a few lookups and</div><div>processing simple HTTP requests; talking to nova would take most</div><div>of the time and this only happens at boot time). </div><div><br></div><div>I would probably aim for a Python implementation reusing/importing</div><div>code from neutron tree but I'm not sure how we want to deal with</div><div>changes in neutron codebase (we're actually importing code now).</div><div>Looking forward to reading your thoughts :)</div><div><br></div><div>Thanks,</div><div>Daniel</div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/452811/" target="_blank">https://review.openstack.o<wbr>rg/#/c/452811/</a></div></div>
</div><br></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Rackspace Australia</div>
</div></div>