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

51–60 of 164 posts

Re: Weave is kinda slow

#51

Post by msutherl »

lclarkmichalek wrote: post #49
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…

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption https://twitter.com/lclarkmichalek/status/544882194456776705

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you."

That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more depth in an email?" Even if you're dealing with a troll, this is still the best strategy.

Re: Weave is kinda slow

#52

Post by weavenetwork »

weavenetwork wrote: post #44
hueving wrote: post #30

Earlier quoted context omitted.

>weave has lots of very happy users who find that weave is plenty fast enough for their purposes That just means that your users aren't using it for large production workloads or they are just wasting excessive resources to make up for it.

That's an entirely subjective statement. What do you mean by 'large'?

I should add that one way to get more throughput is to use more than one CPU.

Re: Weave is kinda slow

#53

Post by weavenetwork »

wmf wrote: post #11
hb42 wrote: post #4

Earlier quoted context omitted.

Is there any solution based on openvswitch ? If using vxlan to encapsulate containers L2 frames, the openvswitch kernel module should be able to route packets very well with much lower overhead than any userspace solution that do not access the nic memory directly.

SocketPlane or OVN.

I haven't seen those used in the wild yet, but fwiw, weave is working on a 'fast data path' that uses the same kernel path as ovs

Re: Weave is kinda slow

#55

Post by weavenetwork »

leg100 wrote: post #20
SEJeff wrote: post #8

flannel appears to be what kubernetes is using as well and I know it is what RedHat is using for their OpenShift platform ontop of k8. It seems like the obvious path forward.

Flannel relies on etcd. I had stability issues with v1 of etcd which meant flannel couldn't route packets. Since then, the idea of using an immature SDN atop an immature distributed key value store fills me with dread.

You can of course use etcd with weave... indeed weave can be run with no dependencies, so it may make sense as a way to bootstrap etcd ;-)

Re: Weave is kinda slow

#56

Post by weavenetwork »

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…

as laurie mentions in his article, you can easily use off the shelf security solutions with weave... the point of the current crypto is to provide something basic that works. we chose nacl for ease of implementation primarily. happy to add more types of security in the future. help would be welcomed!

Re: Weave is kinda slow

#57

Post by pnathan »

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…

The 'good enough' attitude does not lead to quality in the long run. It drags the entire system down. (C, PHP, Windows, etc).

Re: Weave is kinda slow

#58

Post by weavenetwork »

msutherl wrote: post #51
lclarkmichalek wrote: post #49

Earlier quoted context omitted.

Yeah, I feel a little guilty after writing this article, as the speed of the implementation is simply a detail. However, I feel no such guilt in condemning Weave's security. This is a conversation I had with @weave a while ago about their encryption https://twitter.com/lclarkmichalek/status/544882194456776705

This "our project is open source, feel free to submit a patch" dismissal is so passive aggressive. If you mean "fuck you," then just say "fuck you." That said, you shouldn't be saying "fuck you" in the first place: it's rude, it contributes to bad vibes in the OSS community, and it hurts you more than anybody. Try instead something like: "I'm having trouble understanding your argument, do you mind explaining in more…

I don't think anyone meant, or said, "fuck you". Why are you even implying such a thing?

Ultimately we can't work on even a fraction of the features that every person wants, and Laurie said his idea was simple to implement... so why not show how it's done? Honestly, it's not that sinister and it is certainly not rude.

Re: Weave is kinda slow

#59

Post by tracker1 »

karmakaze wrote: post #18
SEJeff wrote: post #8

flannel appears to be what kubernetes is using as well and I know it is what RedHat is using for their OpenShift platform ontop of k8. It seems like the obvious path forward.

More and more, I'm finding I like what comes from the CoreOS group.

I have to agree... I do hope to see something close to a drop-in coreos cluster on a number of networks that becomes easier to use in practice and on in-house servers... The reliability is still a concern, and when you are using a PFM (pure f*ing magic) solution, it needs to be rock solid. I think within 1-2 years CoreOS will be a choice solution... unfortunately I can't wait for that, and don't have the time to become intimate with every detail therein.

Although etcd had a lot of issues even when I was in the evaluation stage... I setup a dev cluster, having a node running on half a dozen machines (developer workstations included) in the office. The etcd cluster broke 3-4 times before I abandoned the thought of using it. With the 2.x release, my test network (3 virtual servers) was a lot more reliable, but I decided I didn't need it that much, opting to use my cloud provider's table solution for maintaining my minimal configuration...

For my deployment, the cluster is relatively small, 3 nodes mainly for redunjdancy... our load could pretty easily be handled by a single larger server. That said, I decided to just use dokku-alt for deployments directly to each server (each service with two instances on each server). To make deployments easier to use, I have internal dns setup with wildcards using v#-#-#.instance-#.service.host.domain.local as a deploy pattern for versioned targets and instance-#.service.host.domain.local for default instances. I have two nginx servers setup for ssl, spdy termination and caching configured to relay requests to the dokku cluster for user-facing services. This is turning out to be simpler than implementing etcd/flannel for that communications layer.

Each instance is passed relevant information regarding the host/service information to report it's own health to table storage, internal communication is using ZeroMQ req/res interfaces to minimize communication overhead, and allow for reconnects. Which is working a little better than relying on WebService/REST interfaces internally.

Re: Weave is kinda slow

#60

Post by swansonc »

justincormack wrote: post #17
api wrote: post #9

Networking is a disaster. Kernel level networking is nice, but that requires access to the kernel which you can't provide in a container. Doing so means containers no longer contain. IPV6 was supposed to solve a lot of this by having an address space so huge you could easily give every vm host a few billion IPs. But nobody uses it.

Hey some of us believe that ipv6 is a good solution for containers. There are even products that support it (like Calico http://calicoproject.org/ ) and even a few cloud providers (not digital ocean who think that 16 ipv6 addresses is ipv6). If you want a real ip/ipv6 stack for your container, try unikernels.

Thank's for the IPv6 love on Project Calico, Justin. Have you been testing Calico's v6? If so, we'd love to talk to you (disclosure, I'm on the project calico team).
Post reply on HN