y errors that it reports.)
>
> My guess is that developing features for both implementations won't be
> much of a burden, beyond the burden of remembering to do it, because it
> should be easy to write DDlog for common features, not really harder
> (maybe easier) than writing the C.
I think this is implied based on the description of how ovn-northd
would work, but do you expect to make a completely seamless drop-in
replacement (aside from build-time and run-time dependencies? All
parameters would be identical, no new configuration, and requiring
zero change to integrations project like ovn-kubernetes or the
OpenStack OVN integration?
In terms of "proven in practice", OVN is at a stage where it's being
used in production, so ideally we set a very high bar for a switchover
like this. It sounds like you're planning for that by enabling
implementations to work in parallel instead of forcing a hard cutover
early. I would hope for something like multiple releases of a new
implementation in experimental state, allowing plenty of time for
testing in realistic, larger scale environments, and relying on
reports of significant successes before a cutover.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
packet is redundantly
> processed in logical switch's egress pipeline on both local and remote
> hypervisors.
Have you identified a problem caused by this behavior?
Thanks,
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
On Fri, Apr 13, 2018 at 9:01 PM, Russell Bryant <russ...@ovn.org> wrote:
> On Fri, Apr 13, 2018 at 5:27 PM, Ben Pfaff <b...@ovn.org> wrote:
>> On Wed, Apr 11, 2018 at 07:44:25PM +0530, Anil Venkata wrote:
>>> vm created on a vlan tenant network is using
compute nodes like
today.
3) Figure out a way for OVN to do this redirect to the gateway host
over a VLAN network. I suspect this isn't trivial and honestly
haven't spent the time to figure out what it would take, but this does
seem like the ideal behavior.
--
Russell Bryant
___
is the main benefit of putting it in 2.9 to me -- it makes it
easier to work on integration.
If it's in 2.9, OpenStack (as one example) can do integration work and
merge it as an optional feature. If it's deferred to 2.10, that work
can begin, but the patches can't be merged until th
rthd, and one of the machines running ovn-controller and ovs-vswitchd.
> Thanks,
> —Kevin
>
>
> Hi Kevin,
>
> In short, I agree with Ethan's assessment that the hmap numbers appear
> large. The ACLs, combined with ovn-controller's algorithms, are causing
> that. The
I support adding some OVN testing, especially scale testing. There is a
>> dormant ovn scale testing project that might be a place to start (I've
>> never looked at it personally):
>> https://github.com/openvswitch/ovn-scale-test
>>
>
>
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
n. You can
use those namespaces like you did before.
The other option would be to manually create a Neutron port, and then
manually create an interface in a namespace for that Neutron port. I
can send instructions if needed ...
--
Russell Bryant
___
oadmap? Somebody working on it? Is there a ticket that we
> can track?
Nobody is currently working on it.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
rue"}
> Port_Binding "6fe3cab5-5f84-44c8-90f2-64c21b489c62"
> Chassis "4180095d-1528-4063-b135-5dc0abc4ecee"
> hostname: "compute2"
> Encap geneve
> ip: "192.168.122.207"
> options: {csum="true"}
>
You should see "redirect-chassis=" in the options column.
That identifies the chassis hosting the gateway router.
> ~~~
>
>
>
> Thanks & Regards,
> Vikrant Aggarwal
>
>
> ___
> discuss mailing list
> disc...@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
>
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
gt; neutron net-create NET-EXT --provider:network_type flat
> --provider:physical_network br-ex --router:external=true --shared
>
> Once i corrected option '--provider' option with
> '--provider:physical_network provider', its working fine on compute node.
>
> -Jai
>
>
> ___
r-ex, it
> works fine and no error is thrown.
>
>
> Is this a bug or the field before ":" in this external-id represents bridge
> name.
The error message indicates that a "localnet" was created with a
"network_name" of "br-ex". The "network
tion is not tested and will probably break
eventually. I recommend using Ocata Neutron as well.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
able to specify only a subset of hosts that should be used
as gateways.
2) We need some HA capabilities to handle when a host handling a gateway
goes down.
--
Russell Bryant
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
16 matches
Mail list logo
