Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Weave is kinda slow

generictestdomain.net

Post reply on HN
Print view View original

121–130 of 164 posts

Re: Weave is kinda slow

#121

Post by Confusion »

otterley wrote: post #102
Confusion wrote: post #81

Earlier quoted context omitted.

I read the article: if they are, that is quite unclear to me. Possible answers that are discussed are only 'some sort of IP encapsulation', which is vague and GRE, which is just a single solution. He doesn't seem to disapprove of VXlan, so probably something was missing in 'IP encapsulation and GRE'. Was 'all problems solved decades ago' merely hyperbole or is there actually something to it?

Is GRE inadequate? A single solution that solves most cases, is codified in an RFC, and has mature, reliable, performant implementations sounds like a winner to me.

I don't know if GRE is inadequate: if I knew that, I wouldn't need to ask these questions. The author doesn't disapprove of VXlan, so there must be something insufficient in GRE.

Look, I'm just trying to understand the playing field here, for when the moment comes that I need that knowledge. I don't currently have a need for funky networking between Docker containers, but I do have Docker containers and can imagine a future need for funky networking. The article slams new technologies, but doesn't clearly explain the alternatives, which is what I'm interested in, so I'm asking follow-up questions. There is nothing rhetorical here.

Re: Weave is kinda slow

#122

Post by mradestock »

jheriko wrote: post #114
bascule wrote: post #39

Weave has other issues... like they homebrewed their own ECDHE-PSK-based transport encryption protocol on top of NaCl. Homebrewing your own crypto, especially transport encryption which has to solve problems like key exchange, replay attacks, etc is generally the wrong answer. Also, even if they were using a standard transport encryption like SSL/TLS or IPSEC, PSKs are generally frowned upon for anything other than p…

"they do not use a password hashing function" this is a bit of a facepalm whenever i hear this.

> "they do not use a password hashing function"

From the weave crypto docs at http://weaveworks.github.io/weave/how-it-works.html#crypto:

"The public key from the remote peer is combined with the private key for the local peer in the usual Diffie-Hellman way, resulting in both peers arriving at the same shared key. To this is appended the supplied password, and the result is hashed through SHA256, to form the final ephemeral session key."

Disclaimer: I work on Weave.

Re: Weave is kinda slow

#123

Post by juliangregorian »

yellowapple wrote: post #110
juliangregorian wrote: post #80

Earlier quoted context omitted.

I find your attitude the ruder. Users of paid products have the right to complain about stuff like that; it's literally what they paid for. Users of open source projects have no such right: if you know what to do, why not make yourself useful instead of bitching out someone who's volunteered their free time to make your life easier? I have very little patience with armchair pundits myself, if you submit a pull reques…

I'm pretty sure the point is more that - had Weave used a standard and already-vetted encryption method instead of rolling their own crypto - they could have put that free time into more useful things instead of now having to maintain yet another crypto implementation on top of their main project. This isn't to say that there's never room for improvement in the crypto space - I personally disagree with the assertion…

Weave had their reasons. I don't profess to understand the space well enough to chime in, but that much is clear from the twitter excerpt.

Re: Weave is kinda slow

#124

Post by weavenetwork »

pnathan wrote: post #104
markbnj wrote: post #86

Earlier quoted context omitted.

Except that people who can recognize when something is indeed "good enough" and then move on to the next most important thing are ultimately the only people who get things done and accomplish goals.

That's a false dichotomy: the difference between good work and shoddy work is much different than the difference between perfect work and shoddy work.

Paul, I think our work is good. We thought about our approach very carefully.. And we have built systems like this before. The main difficulty is to combine moving fast with limited resources, with delivering something supportable and improvable, without creating technical debt.

Re: Weave is kinda slow

#125

Post by weavenetwork »

yellowapple wrote: post #109
weavenetwork wrote: post #84

Earlier quoted context omitted.

I'm sorry but I find your interpretations of 1-4 completely uncharitable and unreasonable.

I don't; if anything, I personally find them too charitable and reasonable. Just admit that you (if you're the one who wrote that response; it's not exactly clear who's who in this discussion...) were being a bit of a twit and move on. We all do it; I do it, the girl next door does it, my grandma even does it and she's the nicest person I know. There's no shame in being honest about it.

No, for example it is 100% uncharitable and unreasonble to assert that "please" is sarcastic. The truth is quite the opposite.

Re: Weave is kinda slow

#126

Post by weavenetwork »

yellowapple wrote: post #110
juliangregorian wrote: post #80

Earlier quoted context omitted.

I find your attitude the ruder. Users of paid products have the right to complain about stuff like that; it's literally what they paid for. Users of open source projects have no such right: if you know what to do, why not make yourself useful instead of bitching out someone who's volunteered their free time to make your life easier? I have very little patience with armchair pundits myself, if you submit a pull reques…

I'm pretty sure the point is more that - had Weave used a standard and already-vetted encryption method instead of rolling their own crypto - they could have put that free time into more useful things instead of now having to maintain yet another crypto implementation on top of their main project. This isn't to say that there's never room for improvement in the crypto space - I personally disagree with the assertion…

We did not roll our own crypto. We used NaCl. The rationale is explained here - http://weaveworks.github.io/weave/how-it-works.html#crypto We agree that other approaches are possible, but this is the one we picked for our first version.

Re: Weave is kinda slow

#127

Post by weavenetwork »

yellowapple wrote: post #111
weavenetwork wrote: post #87

Earlier quoted context omitted.

True. We did try ipsec, and couldn't find an implementation that was oss, demonstrably safe, and easy enough to pull into a first release. As weave matures, we'd love to work with experts to implement standard solutions, even if they are costly to put in place.

OpenBSD's implementation checks off at least the first two boxes, though the third would be a bit difficult in the GNU/Linux world.

We are open to recommendations, help and overall insight from expert contributors in security. As many people on this thread have pointed out, it is a big and complex world..

Re: Weave is kinda slow

#128

Post by mdekkers »

grkvlt wrote: post #38
weavenetwork wrote: post #22

hello, weave here. a few very quick comments! weave has lots of very happy users who find that weave is plenty fast enough for their purposes, see eg http://blog.weave.works/2015/02/24/get-your-kicks-on-cloud66... the strong points of weave network, as it is right now, are ease of use (not to be sniffed at), and enormous flexibility. it is really quite easy to create an application involving containers, that runs any…

I'd agree that Weave is great at what it does, which is providing just-enough-networking to make Docker applications as easy to design and construct as applications running on a normal LAN. This is a huge win, since I don't have to worry about portmappers and trying to discover what dynamically allocated ports are being used at runtime to connect two services. I use Weave as the default SDN for Clocker [1] because of…

I REALLY wish that Clocker would support (and document how to use) something besides Weave - weave is intolerably slow for anything that requires some kind of more serious throughput between nodes. It is very, very unfortunate Clocker doesn't document how to not use Weave (for example, simply use whatever is already in place) as the rest of Clocker rocks, and the seemingly hard dependency on Weave makes it un-deployable for serious production use.

I did pop into their IRc channel a few times with a question around this, but over the space of 3 days all activity on the IRC channel was tumbleweed and crickets..

Re: Weave is kinda slow

#129

Post by weavenetwork »

mdekkers wrote: post #128
grkvlt wrote: post #38

Earlier quoted context omitted.

I'd agree that Weave is great at what it does, which is providing just-enough-networking to make Docker applications as easy to design and construct as applications running on a normal LAN. This is a huge win, since I don't have to worry about portmappers and trying to discover what dynamically allocated ports are being used at runtime to connect two services. I use Weave as the default SDN for Clocker [1] because of…

I REALLY wish that Clocker would support (and document how to use) something besides Weave - weave is intolerably slow for anything that requires some kind of more serious throughput between nodes. It is very, very unfortunate Clocker doesn't document how to not use Weave (for example, simply use whatever is already in place) as the rest of Clocker rocks, and the seemingly hard dependency on Weave makes it un-deploya…

What throughput do you need, on a per-host basis?

Re: Weave is kinda slow

#130

Post by grkvlt »

mdekkers wrote: post #128
grkvlt wrote: post #38

Earlier quoted context omitted.

I'd agree that Weave is great at what it does, which is providing just-enough-networking to make Docker applications as easy to design and construct as applications running on a normal LAN. This is a huge win, since I don't have to worry about portmappers and trying to discover what dynamically allocated ports are being used at runtime to connect two services. I use Weave as the default SDN for Clocker [1] because of…

I REALLY wish that Clocker would support (and document how to use) something besides Weave - weave is intolerably slow for anything that requires some kind of more serious throughput between nodes. It is very, very unfortunate Clocker doesn't document how to not use Weave (for example, simply use whatever is already in place) as the rest of Clocker rocks, and the seemingly hard dependency on Weave makes it un-deploya…

The latest version of Clocker does support Calico as well, now! But I agree there isn't much in the way of documentation on how to change this. I updated the README and the main page at http://clocker.io/ to reflect the changes in Clocker 0.8.1 but it's not immediately obvious. Try this:

    ./bin/clocker.sh jclouds:provider:region calico
Post reply on HN