[ovs-dev] Neutron Container integration.

Armando M. armamig at gmail.com
Wed Apr 22 16:27:52 UTC 2015


On 22 April 2015 at 08:27, Russell Bryant <rbryant at redhat.com> wrote:

> On 04/22/2015 11:18 AM, Thomas Graf wrote:
> > On 04/22/15 at 10:56am, Russell Bryant wrote:
> >> Cool stuff.  It looks like it will help.  To be clear though, what I
> >> think we need is an HTTP callback.  Neutron needs to be able to notify
> >> an arbitrary system instead of specifically Nova that a port is ready.
> >>
> >> Another way to go about this would be to use Ceilometer.  I think
> >> Ceilometer could collect port state change notifications off of the
> >> message bus and an arbitrary system could create alarms on port state
> >> changes.  However, I think we'd rather avoid that dependency.
> >>
> >> There's actually a thread on openstack-dev discussing the more general
> >> problem here:
> >>
> >>
> http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.html
> >>
> >> There are many use cases where we need to be able to communicate
> >> information back to the API user (which would be the container manager
> >> in this case).  We don't have a great common solution for it, really.
> >>
> >> Going back to the issue at hand, another option would be to just
> >> implement the same API call that Nova does for receiving the updates.
> >> You could then configure Neutron to point at that instead of a Nova
> install.
> >>
> >>
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py
>
> Actually, this won't work.  In the case we're talking about, Neutron
> does need to be sending these events to a real Nova.  There's just a
> subset of them that need to be going to a container manager, instead.
> Also, the container manager isn't going to be a single static thing that
> you can point Neutron at in a config file.
>
> > An alternative approach is to insert an adapter in front of the
> > container runtime which performs a connectivity test with a timeout
> > and delays spawning the application until that succeed.
> >
> > For Docker this would be a simple pre-hook.
> >
> > The connectivity test could include reaching a link local address
> > on the host bridge or even a remote endpoint.
> >
> > In theory this sounds more scalable and allows to bring up containers
> > while the host is temporarily isolated (unless remote endpoints are
> > used for the connectivity check).
> >
>
> Yeah, something like that sounds nice.  What we're basically waiting for
> is to make sure OVN has noticed the new port and has configured the
> appropriate flows in the local switch.  Having a better chance of the
> network being operational when the (VM or container) starts is a better
> user experience, I think.  Ideally, whatever is running should just
> retry connections if they fail at first anyway if it's not perfect.
>

What Thomas is proposing has also the benefit of being independent of the
underlying networking solution. That said the adapter itself could choose
to implement a 'readiness check' via connectivity test or via a web hook,
as Russell's initial proposal. That said, the callback mechanism provided
in Kilo, as Kyle pointed out, could be leveraged to decouple the Neutron's
L2 agent (which emits the PORT is READY event) and the element that is in
charge of telling to the container manager that the port is indeed ready.
That element can talk over REST, RPC, IPC or whatever you fancy.

I wouldn't wait for the event to go back to the Neutron Server (which is
where the nova notifier is), IMO that architecture is flawed.

HTH
Armando


>
> --
> Russell Bryant
>



More information about the dev mailing list