Open Stack

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.

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.

Do you think the design your proposing will be extensible like that?

Thanks,
Michael




On Fri, May 5, 2017 at 10:07 PM, Daniel Alvarez Sanchez <dalvarez at redhat.com
> wrote:

> Hi folks,
>
> Now that it looks like the metadata proposal is more refined [0], I'd like
> to get some feedback from you on the driver implementation.
>
> The ovn-metadata-agent in networking-ovn will be responsible for
> creating the namespaces, spawning haproxies and so on. But also,
> it must implement most of the "old" neutron-metadata-agent functionality
> which listens on a UNIX socket and receives requests from haproxy,
> adds some headers and forwards them to Nova. This means that we can
> import/reuse big part of neutron code.
>
> I wonder what you guys think about depending on neutron tree for the
> agent implementation despite we can benefit from a lot of code reuse.
> On the other hand, if we want to get rid of this dependency, we could
> probably write the agent "from scratch" in C (what about having C
> code in the networking-ovn repo?) and, at the same time, it should
> buy us a performance boost (probably not very noticeable since it'll
> respond to requests from local VMs involving a few lookups and
> processing simple HTTP requests; talking to nova would take most
> of the time and this only happens at boot time).
>
> I would probably aim for a Python implementation reusing/importing
> code from neutron tree but I'm not sure how we want to deal with
> changes in neutron codebase (we're actually importing code now).
> Looking forward to reading your thoughts :)
>
> Thanks,
> Daniel
>
> [0] https://review.openstack.org/#/c/452811/
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Rackspace Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170508/657697c1/attachment.html>