On Wed, May 7, 2014 at 9:19 AM, Mathieu Rohon <mathieu.ro...@gmail.com> wrote: > Hi ML2er and others, > > I'm considering discussions around ML2 for the summit. Unfortunatly I > won't attend the summit, so I'll try to participate through the > mailing list and etherpads. > Bummer! Was looking forward to seeing you Mathieu.
> I'm especially interested in extension support by Mechanism Driver[1] > and Modular agent[2]. During the Juno cycle I'll work on the capacity > to propagate IPVPN informations (route-target) down to the agent, so > that the agent can manage MPLS encapsulation. > I think that the easiest way to do that is to enhance > get_device_details() RPC message to add network extension informations > of the concerned port in the dict sent. > > Moreover I think this approach could be generalized, and > get_device_details() in the agent should return serialized information > of a port with every extension informations (security_group, > port_binding...). When the core datamodel or the extension datamodel > would be modified, this would result in a port_update() with the > updated serialization of the datamodel. This way, we could get rid of > security-group and l2pop RPC. Modular agent wouldn't need to deal with > one driver by extension which need to register its RPC callbacks. > This an interesting idea for sure. I think adding some notes to the etherpads and a ML discussion is in order here. You should also propose this as both a BP in the neutron-specs repository, and also add this to a future ML2 meeting agenda. > Those informations should also be stored in ML2 driver context. When a > port is created by ML2 plugin, it calls super() for creating core > datamodel, which will return a dict without extension informations, > because extension informations in the Rest call has not been processed > yet. But once the plugin call its core extension, it should call MD > registered extensions as proposed by nader here [4] and then call > make_port_dict(with extension), or an equivalent serialization > function, to create the driver context. this seralization function > would be used by get_device_details() RPC callbacks too. > > Regards, > > Mathieu > > [1]https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support > [2]https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent > [3]http://summit.openstack.org/cfp/details/240 > [4]https://review.openstack.org/#/c/89211/ > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
