Open Stack

On 01/14/2013 02:32 PM, Salvatore Orlando wrote:
> Hi Bob,
> 
> I am forwarding your comments on this blueprint to the dev mailing
> list, as I don't find the lp whiteboard practical for discussions.
> I hope this is ok for you; please see my comments inline.

No problem, as long as the BP(s) get updated if the discussion results
in significant changes.

> 
> The bottom line is that it seems it makes sense to postpone this work
> item (move provider networks into core), at least until the modular
> plugin is not merged.

I agree, assuming you mean "merged" rather than "not merged".

> If I had to rank priorities of work items, I'd surely rank the modular
> plugin higher. I don't think there will be an outcry or outrage if
> provider networks remain an extension for Grizzly.
> What are your thoughts?

I concur.

> 
> Regards,
> Salvatore
> 
> On 14 January 2013 15:45, Robert Kukura <rkukura at redhat.com> wrote:
>> Blueprint changed by Robert Kukura:
>>
>> Whiteboard set to:
>> I'm not opposed to moving the provider extension API to the core API for
>> Grizzly. But I do not think the data models dealing with representing
>> provider attributes and especially network bindings should be moved to
>> the core DB models quite yet.
> 
> I'm not feeling in a rush for doing this db change, nor for bringing
> the extension into the core; this was the direction provided at the
> summit, and I'm just applying it!

I do recall that direction, but wasn't rushing it due to possible
changes coming from ML2.

Also, there are still plugins that do not implement the providernet
extension, so we'd need to at least have an "unspecified" network_type
to be returned by those if it were core.


> From a DB model perspective, I see code repeated across plugins (model
> classes and routines accessing them). I think that whenever possible
> these situations should be avoided.

Agreed, but the set of network_types supported varies between plugins,
so its not clear the core can fully implement the provider details. In
my view, the driver-based ML2 approach is the best way to reduce the
redundant code for this.

> 
>>
>> For one thing, the set of supported network_type values needs to be
>> open-ended. We should not have to update the core just because a plugin
>> implements a new network type.
> 
> Yes, we don't want to. As a part of this blueprint I was planning on a
> mechanism which will allow the plugin to declare supported network
> types, and probably criteria for validating the other attributes.
> I have a TODO in the code, but unfortunately no LP tracker for this.

Even if/when the provider API gets moved to core, I'm not sure the core
would need to do much validation. Validating the physical_network and
segmentation_id values that go with each network_type is
plugin-specific, so why not have the core allow any string for
network_type, and make it the plugin's responsibility to reject
unsupported values?

The ML2 plugin internally keeps a mapping between network_type values
and the TypeDriver instance support that type. If a network_type value
isn't found in that mapping, then the plugin raises an exception.
Additional mechanism in the core to declare supported network_types
would not add any value. I think the other plugins also already raise an
exception if they don't support a network_type value (i.e. if 'gre' is
passed to linuxbridge).

> 
> This means at least the validation of
>> network_type and corresponding values for physical_network and
>> segmentation_id need to be implemented in the plugin rather than the
>> core.
> 
> Agreed. I don't see this as a restriction that for the having the APIs
> as part of the core, however.

Right.

> 
>>
>> For another, the Modular L2 plugin will (eventually) support multi-
>> segment networks, where different segments of the same virtual network
>> have different network_type, physical_network, and/or segmentation_id
>> values. The ML2 plugin will be using a NetworkSegment table rather than
>> the NetworkBinding table structures used currently in linuxbridge and
>> openvswitch.
>>
>> As described in the specification under
>> https://blueprints.launchpad.net/quantum/+spec/modular-l2, the current
>> provider attributes will continue to apply for single-segment networks,
>> so moving them to a core API shouldn't hurt anything. But multi-segment
>> networks will have a network_type value of "multi-segment", with
>> provider attributes of individual segments available as a separate
>> NetworkSegment resource.
> 
> I see. The API changes proposed by the modular plugin for dealing with
> multisegment-networks will probably require changes to the provider
> network APIs as well, as I think the sub-resources for describing
> segments will be implemented as a part of this extension (I don't
> think they have been proposed for core, have they?)

Not yet. The ML2 plugin DB schema and driver API are being written in
terms of segments, but the initial patchset (WIP in the next day or two)
most likely won't yet support the extended providernet API resource for
multi-segment networks.

> 
> Finally, when a network is declared as 'multi-segment' - does this map
> to a NetworkBinding record being created in the modular plugin?

Instead of NetworkBinding records, the ML2 plugin uses SegmentBinding
records. These are similar, but the network_id is not the primary key,
so a query by network_id can return multiple records, each with a unique
segment_id.

-Bob

> 
>>
>> -Bob
>>
>> --
>> Move Provider Network APIs into core
>> https://blueprints.launchpad.net/quantum/+spec/pnetapis-into-core
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>