This makes sense to me as well.
It's surely better to have structured data rather then encode them in
resource names.
In the options attribute for a "local" logical port, I guess the "name"
attribute will be the name of some ovs bridge instance where the port is
plugged.
From a neutron integration perspective, will neutron need to store
host:bridge mappings? Or can we just assume that for a given physical
network there will always be a bridge with an assigned name on every host?
Salvatore
On 21 July 2015 at 19:23, Ben Pfaff <b...@nicira.com> wrote:
> On Tue, Jul 14, 2015 at 11:59:30AM -0400, Russell Bryant wrote:
> > On 07/14/2015 10:59 AM, Ben Pfaff wrote:
> > > Here's an a strawman alternative. Instead of representing a provider
> > > network as a single logical network, represent it as a collection of
> > > logical networks, one for each connected port. Each of these logical
> > > networks has only two ports, the VM's port plus a physical port on the
> > > hypervisor where the VM resides (or more likely a patch port to the
> > > bridge that contains the physical port; the other end of the patch port
> > > can be an access port if it's a VLAN provider network). It seems to me
> > > that this models the situation more naturally.
> > >
> > > Thoughts?
> >
> > That's a really interesting idea. Conceptually it seems to map much
> > nicer than the previous approach. A logical port with MACs configured
> > as "unknown" matches the processing needed. I'm going to go down this
> > road and see what I can come up with.
> >
> > Some misc implementation thoughts ...
> >
> > When Neutron creates these ports, it needs to indicate that one of the
> > ports is special and maps to local connectivity to the provider network.
> > The ovn-controller-vtep work has similar needs and is doing so with a
> > special port name that follows a particular pattern.
> >
> > In the case of ovn-controller-vtep, it's using the pattern:
> >
> > <physical switch name>_<vtep logical switch name>
> >
> > For provider networks, I need:
> >
> > - physical network name, which maps to a local ovs bridge
> > determined by configuration local to each ovn-controller
> >
> > - Optionally a VLAN ID
> >
> > I was previously thinking that special names was fine, but maybe we
> > should go ahead and add attributes to the logical port in OVN_Northbound
> > to handle this.
> >
> > For reference, the current schema is:
> >
> > > "Logical_Port": {
> > > "columns": {
> > > "name": {"type": "string"},
> > > "parent_name": {"type": {"key": "string", "min": 0,
> "max": 1}},
> > > "tag": {
> > > "type": {"key": {"type": "integer",
> > > "minInteger": 0,
> > > "maxInteger": 4095},
> > > "min": 0, "max": 1}},
> > > "macs": {"type": {"key": "string",
> > > "min": 0,
> > > "max": "unlimited"}},
> > > "port_security": {"type": {"key": "string",
> > > "min": 0,
> > > "max": "unlimited"}},
> > > "up": {"type": {"key": "boolean", "min": 0, "max": 1}},
> > > "enabled": {"type": {"key": "boolean", "min": 0,
> "max": 1}},
> > > "external_ids": {
> > > "type": {"key": "string", "value": "string",
> > > "min": 0, "max": "unlimited"}}},
> > > "indexes": [["name"]],
> > > "isRoot": false},
> >
> > We could add a new string column called "type". Possible values could
> be:
> >
> > - (blank). The current behavior.
> >
> > - vtep : This logical port represents a connection to a logical switch
> > on a VTEP enabled switch
> >
> > - local : This logical port represents a connection to an OVS bridge
> > that exists locally to each ovn-controller.
> >
> > Next we could have an "options" column for key-value pairs of options
> > specific to the configured "type". For vtep you'd have the physical and
> > logical switch names. For local you'd have the network name and
> > optionally a VLAN ID.
>
> These all seem like reasonable ideas to me.
> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
