Open Stack

On 12/04/2013 05:37 AM, Zang MingJie wrote:
> 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.

Hi Zang,

Thanks for putting this together - hopefully we can cover this at
tomorrow's ML2 meeting.

> 
> First, introduce a new extension to abandon provider extension.

Doesn't the existing multiprovidernet extension already serve this
purpose? If not, I'd like to understand why a different extension is
needed, or how the multiprovidernet extension API needs to change.

Whether/how/when we abandon the old provider extension seems separable
from whether the multiprovidernet extension is sufficient or needs
replacement/modification. Assuming we do merge your patch, my current
thinking is that we should declare the provider extension deprecated for
ML2 in icehouse, but maintain the ability to use the provider extension
when there is only a single segment and the segment's type can be fully
described with the old provider attributes. We could then remove the
provider extension from ML2 in the J release.

> 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). 

The multiprovidernet extension already does add a "segments" attribute
to network. This attribute is a list of dictionaries, one per segment,
with no constraints on the keys used in the dictionaries. My
understanding of the main objective of your current patch (which I
apologize that I still haven't completed reviewing) is that it allows
type drivers to use arbitrary keys in these dictionaries. Is that correct?

>                      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.

I'm not sure what you mean by "access policy" here. Is this read-only
vs. read/write? Clearly if type drivers can define arbitrary keys, only
they can check access or validate supplied values. Are you suggesting
adding some mechanism to let the API framework know about each type
driver's keys and handle this for them?

> multiprovidernet extension is a good start point, but some modification
> still required.

I'm still not entirely clear on what modifications to the
multiprovidernet API you feel are 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.

Maybe this is the extension API modification you were referring to above
(or maybe not). When I first proposed ML2 and then wrote the blueprint
for multi-segment networks in ML2, I envisioned segments as being
exposed in the API as a new type of REST resource, possibly a
sub-resource of network. But we ended up going with the much simpler
multiprovidernet approach that Aaron Rosen came up with for the NVP
plugin instead.

Regardless of whether we stick with the existing multiprovidernet
extension or switch to an API with segment as a 1st class resource, I
think your idea of adding explicit operations to MechanismManager (and
MechanismDriver I presume) that are called when adding and removing
segments is worth considering. The original thinking was that
MechanismDrivers would see these changes via the network_update
operations. An alternative might be to simply add a
previous_network_segments attribute to NetworkContext so a
MechanismDriver can easily compare it with network_segments in
network_update calls to see what's changed. But your approach may be
more clear and easier to use.

> 
> 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.

I like this idea as well. It might be more realistic to consider after
the monolithic openvswitch and linuxbridge plugins are removed from the
tree in the J cycle, and we only need to worry about keeping the agents
compatible with the ML2 plugin. Or maybe it could be done in icehouse
and compatibility maintained at the RPC level.

-Bob

> 
> [1] https://review.openstack.org/#/c/37893/
> 
> --
> Zang MingJie
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>