On 01/29/2016 09:36 PM, Darrell Lu wrote:
> The following is a proposal regarding how to allow logical
> and physical endpoint contexts for OVN to stay separated, from
> a CMS POV.
>
> A logical endpoint has the form: ls1-port1.
> A physical endpoint has the general form:
> chassis/physical port or location on chassis/encapsulation.
>
> Some advantages for cleanly separating logical and physical
> layers are:
>
> 1) Logical and physical domains can be managed separately; for
> example, by different companies or business units, with minimal
> interaction overhead.
>
> 2)The physical layer details can change without needing to
> change the logical layer; for example, a physical endpoint
> vlan can change without needing to change the logical layer,
> which in OVN resides in the NB DB.
> The physical endpoint encapsulations can even change in future,
> without needing to update the NB DB supported options and/or
> churning the NB DB.
>
> 3) The logical configuration remains simple in that it just needs
> to concern itself with tasks such linking users to services,
> without too much concern about where the services
> or users are presently located.
>
>
> A physical topology CMS or sub-component of a CMS can be
> used to configure physical endpoints in the SB DB directly,
> bypassing the NB DB and northd processing.
I agree with this sort of separation in principle. Some specific
examples would help me understand the proposal, though. You mention
that this applies to both localnet and gateway cases. Can we lay out
some clear workflows before and after the proposed changes?
The simplest localnet example would be connecting a single VM to a
physical network locally attached to a hypervisor.
On the hypervisor running, ovn-controller, we set:
$ ovs-vsctl set open . \
> external-ids:ovn-bridge-mappings=physnet1:br-eth1
Then, we set up the logical connectivity with:
$ ovn-nbctl lswitch-add provnet1
$ ovn-nbctl lport-add provnet1 provnet1-lp1
$ ovn-nbctl lport-set-addresses provnet1-lp1 $MAC
$ ovn-nbctl lport-set-port-security provnet1-lp1 $MAC
$ ovn-nbctl lport-add provnet1 provnet1-physnet1
$ ovn-nbctl lport-set-addresses provnet1-physnet1 unknown
$ ovn-nbctl lport-set-type provnet1-physnet1 localnet
$ ovn-nbctl lport-set-options provnet1-physnet1 \
> network_name=physnet1
Then we can create the VIF on the hypervisor like usual.
How does your proposal modify the workflow for this use case?
It would be nice to see the same sort of thing for gateways. The
OpenStack driver already has code for the current vtep gateway
integration. We set vtep_logical_switch and vtep_physical_switch on a
logical port. What new workflow would we need to implement?
Thanks,
--
Russell Bryant
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
