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 Ben!
__
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 Security/ACL aspect of the protocol - Is t
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
http://openvswi
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 authentication and encryptio
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 bui
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 argument, in the
> sense t
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
wha
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 for the approach of keeping the OVSDB p
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 the
>> central DB a fault tolerant c
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
> ovs-controller im
"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 weren't seeing much performance o
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 continu
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
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 is
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 sens
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 the explanation and the link Russell.
>
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 discussed?
> On Mar 5,
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 testing happening in mul
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 h
Hi Ben,
What's the current thinking around the OVSDB HA and scale solution?
Needless to say, the single SB DB to which all ovn-controllers connect
could be a liability in various production scenarios.
Cheers,
Dan
On Mar 4, 2016 00:48, "Ben Pfaff" wrote:
> Here's my OVN report for the week, sinc
20 matches
Mail list logo
