Hi, all:
I have already written a patch[1] which makes ml2 segment more extensible,
where segments can contains more fields other than physical network and
segmentation id, but there is still a lot of work to do to make the ml2
more extensible. Here are some of my thoughts.
First, introduce a new extension to abandon provider extension. Currently
the provider extension only support physical network and segmentation id,
as a result the net-create and net-show calls can't handle any extra
fields. Because we already have multi-segment support, we may need an
extension which extends the network with only one field, segments; json can
be used to describe segments when accessing the API (net-create/show). But
there comes a new problem, type drivers must check the access policy of
fields inside segment very carefully, there is nowhere to ensure the access
permission other than the type driver. multiprovidernet extension is a good
start point, but some modification still required.
Second, add segment calls to mechanism driver. There is an one-to-many
relation between network and segments, but it is not clear and hide inside
multi-segment implementation, it should be more clear and more extensible,
so people can use it wisely. I want to add some new APIs to mechanism
manager which handles segment relate operations, eg,
segment_create/segment_release, and separate segment operations from
network.
Last, as our l2 agent (ovs-agent) only handles l2 segments operations, and
do nothing with networks or subnets, I wonder if we can remove all network
related code inside agent implementation, and only handle segments, change
lvm map from {network_id->segment/ports} to {segment_id->segment/ports}.
The goal is to make the ovs-agent pure l2 agent.
[1] https://review.openstack.org/#/c/37893/
--
Zang MingJie
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
