<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 8, 2017 at 2:48 AM, Michael Still <span dir="ltr"><<a href="mailto:mikal@stillhq.com" target="_blank">mikal@stillhq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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></blockquote><div><br></div><div><br></div><div>I believe we may focus on achieving parity with the neutron reference implementation first, and later on what you're proposing probably needs to modelled on the neutron side.</div><div><br></div><div>Could you provide a practical example of how that would work anyway?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><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"><div><div class="gmail-h5">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></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><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></div></div></div></div></blockquote></div></div></div></blockquote><div><span style="color:rgb(0,0,0)">Makes sense, you would avoid this way, depending on an extra co-hosted</span></div><div><span style="color:rgb(0,0,0)">service, reducing this way deployment complexity.</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div></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></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">I would try to keep that part in Python, as everything on the networking-ovn</div><div style="color:rgb(0,0,0)">repo. I remember that Jakub made lots of improvements on the</div><div style="color:rgb(0,0,0)">neutron-metadata-agent area by caching, I'd make sure we reuse that if</div><div style="color:rgb(0,0,0)">it's of use to us (not sure if we used it for nova communication or not).</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">The neutron metadata agent, apparently has a get_ports RPC call [2] to</div><div style="color:rgb(0,0,0)">neutron-server plugin. We don't want RPC calls but ovsdb to get that info,</div><div style="color:rgb(0,0,0)">I have vague proof about caching also being used for those requests [1],</div><div style="color:rgb(0,0,0)">but with ovsdb we have that for free.</div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">I don't know, the agent is 300 LOC, it seems to me like a whole re-write in</div><div style="color:rgb(0,0,0)">python (copying whatever is necessary) could be a reasonable way, but I</div><div style="color:rgb(0,0,0)">guess that trying to go down that rabbit hole would tell you better if I'm</div><div style="color:rgb(0,0,0)">wrong or if it makes sense.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div><br></div><div>I would probably aim for a Python implementation </div></div></div></div></div></div></blockquote></div></div></div></blockquote><div><span style="color:rgb(0,0,0)">+1000</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>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></div></div></div></div></blockquote></div></div></div></blockquote><div><br></div><div><div style="color:rgb(0,0,0)">I guess the neutron-ns-metadata haproxy spawning [3] can be reused</div><div style="color:rgb(0,0,0)">from neutron, I wonder if it would make sense to move that to neutron_lib?</div><div style="color:rgb(0,0,0)">I believe that's the key thing that can be reused, </div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">if we don't reuse it: we need to maintain it in two places,</div><div style="color:rgb(0,0,0)">if we reuse it, we can be broken by changes in neutron repo,</div><div style="color:rgb(0,0,0)">but I'm sure we're flexible enough to react to such changes, </div><div style="color:rgb(0,0,0)"><br></div><div style="color:rgb(0,0,0)">Cheers! :D</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div class="gmail-h5"><div dir="ltr"><div class="gmail_quote"><div dir="ltr"><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></div></div>______________________________<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.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
<br></blockquote></div><span class="gmail-HOEnZb"><font color="#888888"><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_8166436717337073369gmail_signature">Rackspace Australia</div>
</font></span></div></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></div></div>