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