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. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
