Re: [ovs-dev] weekly OVN report

On Wed, Mar 9, 2016 at 1:31 AM, Ben Pfaff wrote: > On Tue, Mar 08, 2016 at 08:29:56AM -0500, Russell Bryant wrote: > > It would be nice to see a write up of detailed requirements and how those > > line up with alternatives. > > That's my goal for Thursday. > Looking forward to it

Re: [ovs-dev] weekly OVN report

On Tue, Mar 8, 2016 at 10:29 PM, Russell Bryant wrote: > On Tue, Mar 8, 2016 at 3:15 AM, Amitabha Biswas > wrote: > >> I see a couple of distinct discussions occurring on this thread, maybe >> it’s time to deal with them independently. >> >> >>- The

Re: [ovs-dev] weekly OVN report

On Tue, Mar 08, 2016 at 08:29:56AM -0500, Russell Bryant wrote: > It would be nice to see a write up of detailed requirements and how those > line up with alternatives. That's my goal for Thursday. ___ dev mailing list dev@openvswitch.org

Re: [ovs-dev] weekly OVN report

On Tue, Mar 8, 2016 at 3:15 AM, Amitabha Biswas wrote: > I see a couple of distinct discussions occurring on this thread, maybe > it’s time to deal with them independently. > > >- The Security/ACL aspect of the protocol - Is there some reason why >existing SSL

Re: [ovs-dev] weekly OVN report

I see a couple of distinct discussions occurring on this thread, maybe it’s time to deal with them independently. The Security/ACL aspect of the protocol - Is there some reason why existing SSL authentication and encryption mechanisms is not adequate enough for security. I am not opposed to

Re: [ovs-dev] weekly OVN report

On Mon, Mar 7, 2016 at 9:47 AM, Dan Mihai Dumitriu wrote: > I would argue for a server-side OVSDB to other backend proxy. I would also > argue against a client side (in ovn-controller) abstraction of the other-db > - one reason for this is related to the security/safety

Re: [ovs-dev] weekly OVN report

I would argue for a server-side OVSDB to other backend proxy. I would also argue against a client side (in ovn-controller) abstraction of the other-db - one reason for this is related to the security/safety argument, in the sense that other-db may not have any ACL mechanism, or any way to limit

Re: [ovs-dev] weekly OVN report

Hi Russell, Nice writeup of the issues and potential solutions. We have been thinking along the same lines. Cheers, Dan On Mon, Mar 7, 2016 at 11:29 PM, Russell Bryant wrote: > On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu > wrote: > >> I'd argue

Re: [ovs-dev] weekly OVN report

On Mon, Mar 7, 2016 at 9:29 AM, Russell Bryant wrote: > On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu > wrote: > >> I'd argue for the approach of keeping the OVSDB protocol in place, >> because the SB schema is already there, well understood, and making

Re: [ovs-dev] weekly OVN report

On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu wrote: > I'd argue for the approach of keeping the OVSDB protocol in place, because > the SB schema is already there, well understood, and making the central DB > a fault tolerant cluster would have little or no impact on the

Re: [ovs-dev] weekly OVN report

"dev" wrote on 05/03/2016 10:45:46 PM: > There are basically two possible paths here. One path is to enhance > OVSDB. The other is to switch to a different distributed database. Of > course, in the latter case the question is "which one?" Until recently, > we

Re: [ovs-dev] weekly OVN report

I'd argue for the approach of keeping the OVSDB protocol in place, because the SB schema is already there, well understood, and making the central DB a fault tolerant cluster would have little or no impact on the ovs-controller implementation. It would also allow the current single OVSDB to

Re: [ovs-dev] weekly OVN report

It hadn't honestly occurred to me that it was an option to retain the protocol but change the database. I was assuming that, if OVN switches to a different database, it would adopt the database's own protocol for communication to the cluster. Of course, now that you mention it, there is a degree

Re: [ovs-dev] weekly OVN report

Understood Ben. If the central (NB and/or SB) OVSDB were to be replaced, do you think it would still be preferable to keep the OVSDB protocol between the local ovn-controller and the central control cluster? Or would it be reasonable to consider something like XMPP? Assuming the OVSDB protocol

Re: [ovs-dev] weekly OVN report

There are basically two possible paths here. One path is to enhance OVSDB. The other is to switch to a different distributed database. Of course, in the latter case the question is "which one?" Until recently, we weren't seeing much performance or availability pressure on OVSDB, so it made

Re: [ovs-dev] weekly OVN report

Cool, see you there. On Mar 5, 2016 20:38, "Russell Bryant" wrote: > Yes, we have a weekly OVN IRC meeting in #openvswitch on Freenode on > Thursdays at 10:15 Pacific / 1:15 Eastern. > > On Saturday, March 5, 2016, Dan Mihai Dumitriu wrote: > >> Thanks for

Re: [ovs-dev] weekly OVN report

Yes, we have a weekly OVN IRC meeting in #openvswitch on Freenode on Thursdays at 10:15 Pacific / 1:15 Eastern. On Saturday, March 5, 2016, Dan Mihai Dumitriu wrote: > Thanks for the explanation and the link Russell. > > Is there a regular meeting where this topic might be

Re: [ovs-dev] weekly OVN report

Thanks for the explanation and the link Russell. Is there a regular meeting where this topic might be discussed? On Mar 5, 2016 02:40, "Russell Bryant" wrote: > There's a lot of work happening to improve ovsdb performance (both on the > client and server sides). There's

Re: [ovs-dev] weekly OVN report

There's a lot of work happening to improve ovsdb performance (both on the client and server sides). There's testing happening in multiple environments (physical and simulated) in the hundreds-of-hypervisors range. Interestingly, most of the bottlenecks we're exposing are on the client side. We