Open Stack

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.

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

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

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

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.

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

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

>
> -Bob
>
> --
> Move Provider Network APIs into core
> https://blueprints.launchpad.net/quantum/+spec/pnetapis-into-core