Open Stack

On Wed, May 7, 2014 at 9:19 AM, Mathieu Rohon <mathieu.rohon at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev