text:
Version 0.21.1 CrashLoop

Describe the bug
New version (0.21.1) of weave-gitops could not start and failing with error:
Error: could not initialise authentication server: could not create auth server: could not get secret for cluster user, resource name may not be empty

Environment

Weave-Gitops Version - 0.21.1
Flux Version - 0.31.1
Kubernetes version - 1.22 (AWS EKS)

To Reproduce
Steps to reproduce the behavior:
Use this helm chart and let flux update chart automatically to latest version, which brings 0.21.1
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: www-gitops
  namespace: flux-system
spec:
  chart:
    spec:
      chart: weave-gitops
      sourceRef:
        kind: HelmRepository
        name: www-gitops
  interval: 1h0m0s
  values:
    rbac:
      create: true
      impersonationResources: ["users"]
    adminUser:
      create: true
      createSecret: false
      username: "gitops-user"
---
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  name: www-gitops
  namespace: flux-system
spec:
  interval: 1h0m0s
  type: oci
  url: oci://ghcr.io/weaveworks/charts

Expected behavior
New version of chart successfully deployed
Actual Behavior
After new version of chart deployed, new version is failing with CrashLoopBackoff
Additional Context (screenshots, logs, etc)

I think it's not a bug technically, but mostly configuration problem. Old helm chart had:
viewSecretsResourceNames: ["cluster-user-auth", "oidc-auth"]

New one have only oidc-auth, so it breaks weave-gitops if no oidc-auth configured. To make it work, just updated flux kustomization:
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
  name: www-gitops
  namespace: flux-system
spec:
  chart:
    spec:
      chart: weave-gitops
      sourceRef:
        kind: HelmRepository
        name: www-gitops
  interval: 1h0m0s
  values:
    rbac:
      create: true
      impersonationResources: ["users"]
      viewSecretsResourceNames: ["cluster-user-auth"]
    adminUser:
      create: true
      createSecret: false
      username: "gitops-user"

Hi @selfsk
Yes, we'll take a look at it shortly
cc @opudrovs

@selfsk Thank you for reporting the issue! We'll revert the changes causing the crash tomorrow and will cut another release as soon as the revert changes PR is merged.

Explicitly setting the adminUser.secretName to the old default of cluster-user-auth seems to fix this too.
Should we bring that back as a default or ask for an explicit secretName if it is managed outside of the helm chart?

@foot I suggest we revert the changes, test them properly, re-merge them later and cut an RC before the next release. This will ensure stability.

@selfsk the new release with chart version 4.0.19 is done:
https://github.com/weaveworks/weave-gitops/releases/tag/v0.21.2
I've just installed the new chart with reverted changes, it works without crashes for me. But if you run into any similar issue, please let us know.

authors: chanwit foot opudrovs selfsk


text:
Add releases and flux runtime pages

Adds the list pages according to the provided designs https://www.figma.com/file/IVHnM9iyeFWpd11evtY8ux/Weave-GitOps?node-id=5399%3A12874
Releases/Applications:

Sources Page:

Flux Runtime:

Good progress being made 👍 thanks Jordan
Some comments:
Applications page

Types should be kustomization / Helm Release rather than kustomize
Source in the designs doesn't show the type, but actually I'm ok with it cc @bia
Missing filters (assuming follow up PR)
Name is only one with sort arrow, is this easy to add to other columns?

Sources page

should be sub-menu item under Applications similar to Clusters > templates in WGE.
Types should be Git Repository / Helm Repository / Bucket (i.e. not just Git)
Missing Reference (currently marked as Release in Figma)
Designs are yet to address comments/reflect the doc in notion and as such are missing cluster, namespace and interval/last synced

Flux Runtime page

Image not Images
Default should sort by Cluster.

Types should be kustomization / Helm Release rather than kustomize

Fixed

Missing filters (assuming follow up PR)

@joshri is working on that

Name is only one with sort arrow, is this easy to add to other columns?

Fixed

Sources page

should be sub-menu item under Applications similar to Clusters > templates in WGE.

Follow up created: https://github.com/weaveworks/weave-gitops/issues/1459

Types should be Git Repository / Helm Repository / Bucket (i.e. not just Git)

Fixed

Missing Reference (currently marked as Release in Figma)

Added, but we need to think about what this means for Helm/Bucket

Designs are yet to address comments/reflect the doc in notion and as such are missing cluster, namespace and interval/last synced

Interval added

Flux Runtime page

Image not Images

Fixed, but a Deployment can have multiple images.

Default should sort by Cluster.

Added

Many thanks @jpellizzari

Added, but we need to think about what this means for Helm/Bucket

Both still have status.artifact.revision or do you feel this isn't valuable/there's something else we should look to show?

Fixed, but a Deployment can have multiple images.

Fair point, I wouldn't expect the flux controllers to though? Or am I missing something?

source: gharchive/pull-request

authors: jpellizzari sympatheticmoose

repo: weaveworks/weave-gitops

license_type: permissive

license_source: github-api


text:
Add passing a Writer to the CLI logger.

Test branch.

@opudrovs I happened to fix this in #3027
would you mind reviewing it instead?
We are fixing it with the same logic.

@chanwit approved. Have not tested it yet but it looks like it should work. 🙂

Closed as a test PR.

authors: chanwit opudrovs


text:
"Sometimes containers cannot connect but they still respond to ping"

Seems similar to another report on Slack from @fermayo; TL;DR is that Weave is apparently seeing the same MAC as coming from two different peers, and this happens at the same time as networking gets broken to the container that really owns that MAC.
I tried to recreate locally and failed.
As reported on weave-users Slack:
jakolehm "we have really strange problem with weave net.. sometimes containers cannot connect but they still respond to ping (weave 1.4.5)
and this happens on coreos stable (latest)
and this happens pretty randomly
let's say we have two peers, A and B ... if we send request from peer A to container in peer B we don't see packet in peer B at all
bryan do you see it on the weave bridge?
jakolehm no
only on peer A weave bridge
bryan ok, this is crossing two hosts, so you have two weave bridges (edited)
jakolehm yes
ping seems to work, and we see the packets
bryan Check the destination MAC address does actually correspond to the container you are trying to hit
jakolehm it does, checked
but, ping reply mac was different
jakolehm actually ping reply mac address is something that we cannot find in any of the machines in this cluster
jakolehm actually it seems that request destination mac is wrong also for tcp connections
12:56:37.698792 4e:fa:a8:29:0a:e2 (oui Unknown) > ba:6e:b6:d8:d8:b9 (oui Unknown), ethertype IPv4 (0x0800), length 74: 10.81.31.139.50716 > weave-test-3.gcp-1.kontena.local.http: Flags [S], seq 31933074
77, win 27400, options [mss 1370,sackOK,TS val 286470583 ecr 0,nop,wscale 7], length 0

ba:6e:b6:d8:d8:b9 should be f2:e2:6e:f4:a3:ce
matthias what host does weave think that MAC is on? logs should tell you.
jakolehm
INFO: 2016/07/06 10:42:08.675404 Discovered remote MAC ba:6e:b6:d8:d8:b9 at 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
INFO: 2016/07/06 11:26:34.352968 Expired MAC ba:6e:b6:d8:d8:b9 at 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
INFO: 2016/07/06 11:41:12.600574 Discovered remote MAC ba:6e:b6:d8:d8:b9 at 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
INFO: 2016/07/06 12:07:34.364139 Expired MAC ba:6e:b6:d8:d8:b9 at 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
INFO: 2016/07/06 12:10:06.398987 Discovered remote MAC ba:6e:b6:d8:d8:b9 at 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
INFO: 2016/07/06 12:14:08.173212 Discovered remote MAC ba:6e:b6:d8:d8:b9 at 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
ERRO: 2016/07/06 12:18:01.123991 Captured frame from MAC (ba:6e:b6:d8:d8:b9) associated with another peer 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)
ERRO: 2016/07/06 12:20:26.996998 Captured frame from MAC (ba:6e:b6:d8:d8:b9) associated with another peer 5e:5a:4a:45:b3:a9(gcp-1-4.c.kontena-1162.internal)

jakolehm bryan: what is a "local mac" ... where does weave get that?
bryan It's printed when we see a packet with a source mac we have never seen before, on the weave bridge.
Since there ought to be no way for packets to get onto the bridge except from a locally-running container, we think it's from one of those.
jakolehm but I can't find that mac on "gcp-1-4" machine
bryan it's possible it went away
jakolehm but I restarted weave and it's coming back...
bryan that's interesting
jakolehm one of the first locally discovered macs
bryan I guess you could tcpdump the weave bridge and see if the packet itself gives any clues
this is somewhat consistent with the "MAC associated with another peer" message - if we've never seen the src address before we print "local MAC", and if we have seen it on another peer we print "associated ..."
so, since you do get the latter, it must be something of a race which one is taken as the "real" home of the packet
and the real question is how come we are seeing packets with the same src address on two different weave bridges?
jakolehm
13:59:53.379567 ARP, Request who-has weave-test-3.gcp-1.kontena.local tell 10.81.31.139, length 28
13:59:53.379578 ARP, Reply weave-test-3.gcp-1.kontena.local is-at ba:6e:b6:d8:d8:b9 (oui Unknown), length 28

bryan and is that container on a different machine?
jakolehm yes

The error message is the same as that noted in #2297.

It seems that we can reproduce this pretty easily with 5 node cluster by scaling one service ~20 times up/down (between 0-100 containers).
Weave: 1.4.5
OS: CoreOS 1010.6.0
Kernel: 4.5.7
Docker: 1.10.3

@bboreham was pondering whether we can make a better decision by inspecting the destination mac, i.e. only drop the mac if the source mac appears to be from a different peer and the destination mac is for a local peer.
Which, by my reading of the code, simply means turning the error into a warning and carrying on.
We'd need to think carefully in what situations that might create a loop.
btw, afaict, we'd get this error if a MAC moved or was duplicated. Correct? Surely we ought to handle the former.

Surely we ought to handle the former (MAC move).

We have code in the handler of forwarded packets for that, but not captured packets. Surely we need both. Without the latter when a MAC moves from another peer to ourselves, we will be suppressing all outgoing packets from that MAC, won't we?

Surely we ought to handle the former (MAC move).

Reproduced and filed #2438.

Hi gents, downstream user of Weave. We're experiencing this issue and happy to help in any way we can.

Hi @crockpotveggies - thanks. I have a specific question - are you doing anything particular (unsual?) to migrate MAC addresses? The MACs of weave's ethwe interfaces are generated randomly by the kernel, and given 2^46 possibilities (the top two bits are fixed) the likelihood of clashes is remote, birthday paradox notwithstanding. Under what circumstances is this happening for you? Can you reproduce it reliably?

@jakolehm Could you provide steps for reproducing the issue? Thanks.

@jakolehm @crockpotveggies next time you get the Captured frame from MAC ... associated with another peer ... messages, can you run
ip -d link show vethwe-bridge

on the affected host and see if you have hairpin on in the output? e.g.:
36: vethwe-bridge@vethwe-datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc pfifo_fast master weave state UP mode DEFAULT group default qlen 1000
    link/ether 3e:52:3d:13:ac:3d brd ff:ff:ff:ff:ff:ff promiscuity 1
    veth
    bridge_slave state forwarding priority 32 cost 2 hairpin on guard off root_block off fastleave off learning on flood on addrgenmode eui64

Sorry late reply here, fairly busy on my end. Regarding "taking any steps outside of weave" I can't fully answer the question because, as a downstream user, we rely on what the Docker Cloud agent does for us.
The circumstances leading to failure involve redeploys within our infrastructure. Basically, we "reload" our backend services (which involves around 10 containers to reproduce this issue) and suddenly we start seeing timeouts to our RabbitMQ container and our main database.
When we open up RabbitMQ to a public address and bypass weave so the containers connect to a public IP directly, it completely alleviates the problem.

@awh yes it has hairpin:
$ ip -d link show vethwe-bridge
303: vethwe-bridge@vethwe-datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
mode DEFAULT group default qlen 1000
    link/ether 82:3a:1c:32:d5:1b brd ff:ff:ff:ff:ff:ff promiscuity 1
    veth
    bridge_slave state forwarding priority 32 cost 2 hairpin off guard off root_block off fastleave off learning on
 flood on addrgenmode eui64

bingo! any idea how it ended up like that?

no idea, where should I look? :)

Oh, sorry for confusion.. hairpin is off in that output :/

bah, that output format is terrible.

Thanks @jakolehm - back to the drawing board then!
We'd like to try to replicate what you mentioned earlier:

It seems that we can reproduce this pretty easily with 5 node cluster by scaling one service ~20 times up/down (between 0-100 containers).
Weave: 1.4.5
OS: CoreOS 1010.6.0
Kernel: 4.5.7
Docker: 1.10.3

Could you answer a few more questions?

Nature of the hosts (e.g. bare metal or VM) as well as provider if hosted
Description of the service you mentioned, and how you were driving traffic to it
Orchestrator used for scaling (e.g. swarm, kubernetes, ....)

Essentially as much concrete information as you are able to give about the setup and testing methodology - if there are images and configs you can share so much the better. Thanks!

Hosts: Google Compute Engine, 5 x n1-standard-8 (us-east, spread across 3 az's)
OS: CoreOS Stable (now 1068.8.0)
Services: Rails & Nodejs apps that are behind loadbalancer (haproxy), haproxy does health check periodically to services and shows these connection problems
Orchestrator: Kontena (kontena.io)

kontena attaches containers to weave network using weave attachafter container is started (logic is similar to weave-proxy)

Weave: sleeve mode with password (no fastdp)

We have been trying to reproduce this locally without success :(

Great detail, thanks!

We have been trying to reproduce this locally without success

That's interesting... what're you using locally?

Exactly same stuff but running inside vagrant boxes.

Hi gents, I've been doing packet captures, here's what's coming from ethwe on my main Mongo container, would you like the full file? Is it helpful?

Additionally, here's what eth0 captures on a bare metal server using dockercloud-agent:

I may have identified a culprit. I checked the logs in the router that handles all of our offline processing nodes and found that it seems to think it's under constant attack. Is it possible that Weave is triggering security systems in networks meant to protect against DoS attacks?

Thanks @crockpotveggies - let us digest that. Out of interest, are you using sleeve as well?

@jakolehm @crockpotveggies is there any possibility we could gain interactive access to one of your affected systems when this occurs again?

@awh negative not using sleeve (unless Docker Cloud has implemented it upstream). FYI the IP address shown in the logs is the IP of the router that handles our small on-site datacenter, meaning it came from within.
I'm happy to grant access if it happens again, though I have a feeling we won't see it again. Literally hacked a special version of router software just to accommodate this special case.

I noticed I got a similar entry in a Weave Net log recently; noting it here because we extended the logging to show source and destination MACs in case that was interesting:
ERRO: 2016/10/03 13:46:17.314646 Captured frame from MAC (f6:52:b4:4f:61:0d) to (9a:b5:28:50:8b:26) associated with another peer de:ce:03:46:b0:18(bryan-8gb-lon1-03)
ERRO: 2016/10/03 13:46:17.314748 Captured frame from MAC (f6:52:b4:4f:61:0d) to (9a:b5:28:50:8b:26) associated with another peer de:ce:03:46:b0:18(bryan-8gb-lon1-03)

From other logs I can see the source was a just-started container on bryan-8gb-lon1-03, and the destination was kube-dns on a third host.  Weave Net on bryan-8gb-lon1-03 probably broadcast the DNS query because it did not know the location of the destination MAC at that time.

Note that #2674, released in Weave Net 1.8.2, added more checks and logging which will be useful if this reoccurs.

I debugged the original issue with the GCE cluster in-situ, and this is actually something closer to #1455, with zombie network namespaces that get left behind after the Docker container itself is removed, that still have an ethwe interface configured and attached to the weave bridge on the host.
TCP connections fail with RST -> ECONNREFUSED because the server app process is no longer running in that netns, but ARP and ICMP ping still work because the netns is alive in the kernel.
The symptom of this is a host-side vethweplXXXX where there is no corresponding pid=XXXX anymore, and the peer veth interface cannot be found in any Docker container network sandbox: https://gist.github.com/SpComb/9cc2a7ed46ff708547d09854b78c197f
Unforunately while I've been able to track down these zombie veths and verified that unlinking them from the weave bridge fixes the issue, I haven't been able to figure out why those netns's are leaking.

@SpComb are you running cadvisor?

@SpComb are you running cadvisor?

Yes, but I IIRC dug through the nsenter -p ... -m cat /proc/mounts for cadvisor and there weren't any netns mounts there. docker inspect ... for the cadvisor container shows that it does have the host / fs mounted, but with "Propagation": "rprivate", so the netns mounts shouldn't be propagating...
I can take a better dig at those next time I run across such a zombie to dissect.

@SpComb kernel version?

I'm not sure I noted that down, but it would have been CoreOS stable as of October, so likely Linux 4.7.3

I am experiencing this problem on my Kubernetes cluster. Here are some details:
Kubernetes Version: v1.4.4
Host Operating System: Oracle Linux 7.2 Linux Kernel 4.1.12-61.1.16.el7uek.x86_64
2016-12-09T14:38:00.791531314Z INFO: 2016/12/09 14:38:00.791289 Discovered remote MAC 96:98:93:52:e8:29 at 82:c6:b0:56:fe:a4(node-02)
2016-12-09T14:39:04.945256721Z ERRO: 2016/12/09 14:39:04.945049 Captured frame from MAC (96:98:93:52:e8:29) to (aa:d6:1b:bd:d2:e4) associated with another peer 82:c6:b0:56:fe:a4(node-02)

@Starefossen what does cat /sys/devices/virtual/net/weave/brif/vethwe-bridge/hairpin_mode return on the affected host?

I'm probably having the same issue.
docker: Docker version 1.12.5, build 047e51b/1.12.5
kontena version: 1.1.2
Linux: Linux version 3.10.0-514.6.1.el7.x86_64 (mockbuild@x86-030.build.eng.bos.redhat.com) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-11) (GCC) ) #1 SMP Sat Dec 10 11:15:38 EST 2016
Storage driver: devicemapper
[root]# ip addr
2817: vethwepl7963@if2816: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 36:d6:20:80:bd:80 brd ff:ff:ff:ff:ff:ff link-netnsid 36
2561: veth138dd2e@if2560: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether ae:85:5f:3b:4a:c6 brd ff:ff:ff:ff:ff:ff link-netnsid 18
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 00:50:56:b9:bb:b3 brd ff:ff:ff:ff:ff:ff
    inet 10.193.38.14/26 brd 10.193.38.63 scope global ens192
       valid_lft forever preferred_lft forever
2563: vethwepl7566@if2562: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether ee:3b:7e:50:bb:4f brd ff:ff:ff:ff:ff:ff link-netnsid 17
3: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:85:79:0f:74 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
4: datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UNKNOWN qlen 1000
    link/ether d6:34:e1:5e:3b:ae brd ff:ff:ff:ff:ff:ff
2565: vethwepl8134@if2564: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 32:49:00:30:19:55 brd ff:ff:ff:ff:ff:ff link-netnsid 18
6: weave: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue state UP qlen 1000
    link/ether 4a:b4:26:7b:6c:89 brd ff:ff:ff:ff:ff:ff
    inet 10.81.0.1/16 scope global weave
       valid_lft forever preferred_lft forever
2567: vethbc67172@if2566: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 5e:ad:c4:17:a1:54 brd ff:ff:ff:ff:ff:ff link-netnsid 19
7: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether ee:0c:2e:b5:34:96 brd ff:ff:ff:ff:ff:ff
3337: vethwepl19161@if3336: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 8e:09:f4:81:4a:b1 brd ff:ff:ff:ff:ff:ff link-netnsid 45
9: vethwe-datapath@vethwe-bridge: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master datapath state UP qlen 1000
    link/ether 2a:9e:2c:13:04:ca brd ff:ff:ff:ff:ff:ff
10: vethwe-bridge@vethwe-datapath: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP qlen 1000
    link/ether 76:b7:5a:73:fe:06 brd ff:ff:ff:ff:ff:ff
2571: vethwepl8796@if2570: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 72:68:00:78:c0:00 brd ff:ff:ff:ff:ff:ff link-netnsid 19
3341: vethwepl19781@if3340: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 0a:94:a5:96:7f:34 brd ff:ff:ff:ff:ff:ff link-netnsid 46
2575: vethwepl9143@if2574: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 62:04:15:25:85:ae brd ff:ff:ff:ff:ff:ff link-netnsid 20
3345: vethwepl20347@if3344: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 9a:47:0f:20:e3:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 26
2577: vethwepl9586@if2576: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 56:af:fa:68:86:09 brd ff:ff:ff:ff:ff:ff link-netnsid 21
3603: veth0fedb9d@if3602: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether fe:71:0d:65:6f:45 brd ff:ff:ff:ff:ff:ff link-netnsid 6
3347: vethffb0999@if3346: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 7e:ff:ae:24:e8:2c brd ff:ff:ff:ff:ff:ff link-netnsid 29
2579: vetha23e2bc@if2578: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 52:66:da:fe:79:e1 brd ff:ff:ff:ff:ff:ff link-netnsid 22
3605: vethwepl9350@if3604: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 76:6d:b8:56:94:b8 brd ff:ff:ff:ff:ff:ff link-netnsid 6
3349: vethwepl26401@if3348: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 86:80:62:de:ae:9b brd ff:ff:ff:ff:ff:ff link-netnsid 29
2581: veth7aae92b@if2580: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 1e:26:2e:43:ef:27 brd ff:ff:ff:ff:ff:ff link-netnsid 23
2583: vethwepl10354@if2582: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 1e:b0:24:75:f5:c0 brd ff:ff:ff:ff:ff:ff link-netnsid 22
2585: veth16cd5c7@if2584: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 2a:d1:59:19:19:aa brd ff:ff:ff:ff:ff:ff link-netnsid 24
2587: vethwepl10748@if2586: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 2e:07:33:cb:84:20 brd ff:ff:ff:ff:ff:ff link-netnsid 23
2591: vethwepl11214@if2590: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether fa:9f:4e:9f:5b:c4 brd ff:ff:ff:ff:ff:ff link-netnsid 24
2595: vethwepl11666@if2594: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 3e:38:8a:c3:47:7c brd ff:ff:ff:ff:ff:ff link-netnsid 25
3365: vethwepl8386@if3364: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 2e:1d:4a:6b:5b:6f brd ff:ff:ff:ff:ff:ff link-netnsid 30
3381: vethwepl10930@if3380: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether b2:65:33:4a:88:81 brd ff:ff:ff:ff:ff:ff link-netnsid 43
3385: vethwepl11609@if3384: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 12:cc:58:09:10:bb brd ff:ff:ff:ff:ff:ff link-netnsid 44
3389: vethwepl12234@if3388: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 4a:06:e6:ee:90:ac brd ff:ff:ff:ff:ff:ff link-netnsid 33
3391: veth55f29a7@if3390: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether aa:c0:5e:ce:40:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
3393: vethwepl13508@if3392: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 7a:99:df:df:24:57 brd ff:ff:ff:ff:ff:ff link-netnsid 0
3137: vethwepl24638@if3136: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 9a:e4:41:e2:15:60 brd ff:ff:ff:ff:ff:ff link-netnsid 53
3395: vethd0ab2fa@if3394: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 86:16:c7:ea:df:2b brd ff:ff:ff:ff:ff:ff link-netnsid 1
3397: vethwepl13154@if3396: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 36:6e:2d:76:1a:7f brd ff:ff:ff:ff:ff:ff link-netnsid 1
2653: vethwepl6228@if2652: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 32:47:99:04:80:d1 brd ff:ff:ff:ff:ff:ff link-netnsid 31
2411: vxlan-6784: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 65470 qdisc noqueue master datapath state UNKNOWN qlen 1000
    link/ether fe:aa:25:88:65:72 brd ff:ff:ff:ff:ff:ff
2701: vethwepl17929@if2700: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 6e:35:fa:99:bc:a9 brd ff:ff:ff:ff:ff:ff link-netnsid 28
2705: vethwepl18402@if2704: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 4e:da:f8:65:c6:88 brd ff:ff:ff:ff:ff:ff link-netnsid 37
2709: vethwepl18940@if2708: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 26:33:50:bb:ce:5d brd ff:ff:ff:ff:ff:ff link-netnsid 38
2713: vethwepl19668@if2712: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether d6:e9:30:83:c3:9c brd ff:ff:ff:ff:ff:ff link-netnsid 39
3753: vethwepl23259@if3752: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 96:08:f6:02:73:6d brd ff:ff:ff:ff:ff:ff link-netnsid 9
3757: vethwepl23941@if3756: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether da:5b:8e:10:8d:9e brd ff:ff:ff:ff:ff:ff link-netnsid 10
2479: vethwepl6832@if2478: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 1a:6f:72:3e:6b:41 brd ff:ff:ff:ff:ff:ff link-netnsid 14
3761: vethwepl24474@if3760: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 02:d5:ed:85:db:e7 brd ff:ff:ff:ff:ff:ff link-netnsid 4
3779: veth9ebf941@if3778: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 72:5e:91:e1:fc:81 brd ff:ff:ff:ff:ff:ff link-netnsid 2
3781: vethwepl30712@if3780: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 46:6e:c3:b7:02:50 brd ff:ff:ff:ff:ff:ff link-netnsid 2
3793: vethwepl32388@if3792: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 26:d8:c4:4e:a6:76 brd ff:ff:ff:ff:ff:ff link-netnsid 5
3795: veth31fb42f@if3794: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 2a:4f:d0:ca:f2:f2 brd ff:ff:ff:ff:ff:ff link-netnsid 8
3797: vethwepl590@if3796: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 86:9d:2f:95:3b:ed brd ff:ff:ff:ff:ff:ff link-netnsid 8
3799: veth2be23ec@if3798: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether ea:ba:d7:2e:25:c8 brd ff:ff:ff:ff:ff:ff link-netnsid 12
3801: vethwepl1331@if3800: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether c2:08:f7:8c:74:7e brd ff:ff:ff:ff:ff:ff link-netnsid 12
3803: veth9776d0d@if3802: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether ba:fc:6d:3a:af:9f brd ff:ff:ff:ff:ff:ff link-netnsid 3
3805: vethwepl1894@if3804: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 5e:ea:d9:6c:e1:f9 brd ff:ff:ff:ff:ff:ff link-netnsid 3
2789: vethwepl23742@if2788: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 96:81:59:9e:0e:9f brd ff:ff:ff:ff:ff:ff link-netnsid 32
2533: vethwepl23876@if2532: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 1a:5c:38:b4:9d:00 brd ff:ff:ff:ff:ff:ff link-netnsid 11
2537: vethwepl24545@if2536: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 12:7d:df:ca:79:19 brd ff:ff:ff:ff:ff:ff link-netnsid 13
2795: vethwepl24844@if2794: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 1e:5e:bf:07:1d:db brd ff:ff:ff:ff:ff:ff link-netnsid 27
2797: vethwepl24989@if2796: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether 36:7b:54:87:9b:99 brd ff:ff:ff:ff:ff:ff link-netnsid 41
2541: vethwepl25828@if2540: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether fe:62:ba:24:00:2f brd ff:ff:ff:ff:ff:ff link-netnsid 15
2545: vethwepl28113@if2544: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether da:aa:21:6b:78:27 brd ff:ff:ff:ff:ff:ff link-netnsid 16
3321: vethwepl16816@if3320: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether be:90:4b:41:c5:9b brd ff:ff:ff:ff:ff:ff link-netnsid 42
2813: vethwepl7304@if2812: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1410 qdisc noqueue master weave state UP
    link/ether f6:03:b1:7d:d2:76 brd ff:ff:ff:ff:ff:ff link-netnsid 35
2815: vethce44706@if2814: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP
    link/ether 52:7c:1c:f6:bb:52 brd ff:ff:ff:ff:ff:ff link-netnsid 36

@panuhorsmalahti "the same issue" being "seeing the same MAC as coming from two different peers" ?
Can you show some of the evidence that leads you to that thought?

I can ping and curl the container IP from the host, and can ping the container from another container, but curl doesn't work.
weave-zombie-hunter.sh output:

weave-zombie-hunter.sh output
  ./weave-zombie-hunter.sh
# weave e2:7f:bd:e3:db:d3 @ vethwepl10930: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl10930: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl10930: missing
# weave 02:c5:00:91:95:a4 @ vethwepl10930: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl10930: missing
# weave 02:68:2f:29:fb:27 @ vethwepl10930: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl10930: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl10930: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl10930: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl10930: missing
# weave be:c3:40:d5:7a:98 @ vethwepl10930: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl10930: missing
ip link set vethwepl10930 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl11609: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl11609: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl11609: missing
# weave 02:c5:00:91:95:a4 @ vethwepl11609: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl11609: missing
# weave 02:68:2f:29:fb:27 @ vethwepl11609: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl11609: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl11609: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl11609: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl11609: missing
# weave be:c3:40:d5:7a:98 @ vethwepl11609: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl11609: missing
ip link set vethwepl11609 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl11666: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl11666: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl11666: missing
# weave 02:c5:00:91:95:a4 @ vethwepl11666: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl11666: missing
# weave 02:68:2f:29:fb:27 @ vethwepl11666: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl11666: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl11666: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl11666: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl11666: missing
# weave be:c3:40:d5:7a:98 @ vethwepl11666: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl11666: missing
ip link set vethwepl11666 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl12234: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl12234: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl12234: missing
# weave 02:c5:00:91:95:a4 @ vethwepl12234: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl12234: missing
# weave 02:68:2f:29:fb:27 @ vethwepl12234: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl12234: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl12234: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl12234: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl12234: missing
# weave be:c3:40:d5:7a:98 @ vethwepl12234: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl12234: missing
ip link set vethwepl12234 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl16816: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl16816: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl16816: missing
# weave 02:c5:00:91:95:a4 @ vethwepl16816: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl16816: missing
# weave 02:68:2f:29:fb:27 @ vethwepl16816: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl16816: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl16816: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl16816: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl16816: missing
# weave be:c3:40:d5:7a:98 @ vethwepl16816: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl16816: missing
ip link set vethwepl16816 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl17929: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl17929: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl17929: missing
# weave 02:c5:00:91:95:a4 @ vethwepl17929: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl17929: missing
# weave 02:68:2f:29:fb:27 @ vethwepl17929: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl17929: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl17929: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl17929: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl17929: missing
# weave be:c3:40:d5:7a:98 @ vethwepl17929: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl17929: missing
ip link set vethwepl17929 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl18402: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl18402: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl18402: missing
# weave 02:c5:00:91:95:a4 @ vethwepl18402: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl18402: missing
# weave 02:68:2f:29:fb:27 @ vethwepl18402: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl18402: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl18402: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl18402: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl18402: missing
# weave be:c3:40:d5:7a:98 @ vethwepl18402: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl18402: missing
ip link set vethwepl18402 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl18940: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl18940: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl18940: missing
# weave 02:c5:00:91:95:a4 @ vethwepl18940: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl18940: missing
# weave 02:68:2f:29:fb:27 @ vethwepl18940: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl18940: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl18940: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl18940: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl18940: missing
# weave be:c3:40:d5:7a:98 @ vethwepl18940: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl18940: missing
ip link set vethwepl18940 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl19161: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl19161: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl19161: missing
# weave 02:c5:00:91:95:a4 @ vethwepl19161: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl19161: missing
# weave 02:68:2f:29:fb:27 @ vethwepl19161: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl19161: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl19161: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl19161: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl19161: missing
# weave be:c3:40:d5:7a:98 @ vethwepl19161: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl19161: missing
ip link set vethwepl19161 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl19668: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl19668: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl19668: missing
# weave 02:c5:00:91:95:a4 @ vethwepl19668: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl19668: missing
# weave 02:68:2f:29:fb:27 @ vethwepl19668: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl19668: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl19668: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl19668: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl19668: missing
# weave be:c3:40:d5:7a:98 @ vethwepl19668: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl19668: missing
ip link set vethwepl19668 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl19781: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl19781: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl19781: missing
# weave 02:c5:00:91:95:a4 @ vethwepl19781: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl19781: missing
# weave 02:68:2f:29:fb:27 @ vethwepl19781: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl19781: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl19781: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl19781: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl19781: missing
# weave be:c3:40:d5:7a:98 @ vethwepl19781: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl19781: missing
ip link set vethwepl19781 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl20347: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl20347: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl20347: missing
# weave 02:c5:00:91:95:a4 @ vethwepl20347: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl20347: missing
# weave 02:68:2f:29:fb:27 @ vethwepl20347: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl20347: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl20347: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl20347: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl20347: missing
# weave be:c3:40:d5:7a:98 @ vethwepl20347: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl20347: missing
ip link set vethwepl20347 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl23259: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl23259: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl23259: missing
# weave 02:c5:00:91:95:a4 @ vethwepl23259: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl23259: missing
# weave 02:68:2f:29:fb:27 @ vethwepl23259: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23259: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23259: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl23259: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl23259: missing
# weave be:c3:40:d5:7a:98 @ vethwepl23259: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl23259: missing
ip link set vethwepl23259 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl23742: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl23742: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl23742: missing
# weave 02:c5:00:91:95:a4 @ vethwepl23742: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl23742: missing
# weave 02:68:2f:29:fb:27 @ vethwepl23742: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23742: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23742: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl23742: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl23742: missing
# weave be:c3:40:d5:7a:98 @ vethwepl23742: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl23742: missing
ip link set vethwepl23742 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl23876: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl23876: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl23876: missing
# weave 02:c5:00:91:95:a4 @ vethwepl23876: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl23876: missing
# weave 02:68:2f:29:fb:27 @ vethwepl23876: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23876: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23876: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl23876: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl23876: missing
# weave be:c3:40:d5:7a:98 @ vethwepl23876: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl23876: missing
ip link set vethwepl23876 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl23941: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl23941: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl23941: missing
# weave 02:c5:00:91:95:a4 @ vethwepl23941: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl23941: missing
# weave 02:68:2f:29:fb:27 @ vethwepl23941: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23941: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl23941: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl23941: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl23941: missing
# weave be:c3:40:d5:7a:98 @ vethwepl23941: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl23941: missing
ip link set vethwepl23941 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl24474: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl24474: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl24474: missing
# weave 02:c5:00:91:95:a4 @ vethwepl24474: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl24474: missing
# weave 02:68:2f:29:fb:27 @ vethwepl24474: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24474: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24474: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl24474: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl24474: missing
# weave be:c3:40:d5:7a:98 @ vethwepl24474: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl24474: missing
ip link set vethwepl24474 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl24545: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl24545: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl24545: missing
# weave 02:c5:00:91:95:a4 @ vethwepl24545: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl24545: missing
# weave 02:68:2f:29:fb:27 @ vethwepl24545: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24545: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24545: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl24545: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl24545: missing
# weave be:c3:40:d5:7a:98 @ vethwepl24545: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl24545: missing
ip link set vethwepl24545 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl24638: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl24638: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl24638: missing
# weave 02:c5:00:91:95:a4 @ vethwepl24638: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl24638: missing
# weave 02:68:2f:29:fb:27 @ vethwepl24638: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24638: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24638: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl24638: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl24638: missing
# weave be:c3:40:d5:7a:98 @ vethwepl24638: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl24638: missing
ip link set vethwepl24638 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl24844: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl24844: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl24844: missing
# weave 02:c5:00:91:95:a4 @ vethwepl24844: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl24844: missing
# weave 02:68:2f:29:fb:27 @ vethwepl24844: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24844: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24844: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl24844: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl24844: missing
# weave be:c3:40:d5:7a:98 @ vethwepl24844: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl24844: missing
ip link set vethwepl24844 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl24989: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl24989: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl24989: missing
# weave 02:c5:00:91:95:a4 @ vethwepl24989: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl24989: missing
# weave 02:68:2f:29:fb:27 @ vethwepl24989: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24989: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl24989: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl24989: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl24989: missing
# weave be:c3:40:d5:7a:98 @ vethwepl24989: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl24989: missing
ip link set vethwepl24989 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl25828: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl25828: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl25828: missing
# weave 02:c5:00:91:95:a4 @ vethwepl25828: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl25828: missing
# weave 02:68:2f:29:fb:27 @ vethwepl25828: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl25828: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl25828: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl25828: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl25828: missing
# weave be:c3:40:d5:7a:98 @ vethwepl25828: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl25828: missing
ip link set vethwepl25828 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl28113: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl28113: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl28113: missing
# weave 02:c5:00:91:95:a4 @ vethwepl28113: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl28113: missing
# weave 02:68:2f:29:fb:27 @ vethwepl28113: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl28113: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl28113: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl28113: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl28113: missing
# weave be:c3:40:d5:7a:98 @ vethwepl28113: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl28113: missing
ip link set vethwepl28113 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl32388: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl32388: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl32388: missing
# weave 02:c5:00:91:95:a4 @ vethwepl32388: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl32388: missing
# weave 02:68:2f:29:fb:27 @ vethwepl32388: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl32388: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl32388: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl32388: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl32388: missing
# weave be:c3:40:d5:7a:98 @ vethwepl32388: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl32388: missing
ip link set vethwepl32388 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl6228: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl6228: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl6228: missing
# weave 02:c5:00:91:95:a4 @ vethwepl6228: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl6228: missing
# weave 02:68:2f:29:fb:27 @ vethwepl6228: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl6228: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl6228: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl6228: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl6228: missing
# weave be:c3:40:d5:7a:98 @ vethwepl6228: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl6228: missing
ip link set vethwepl6228 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl6832: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl6832: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl6832: missing
# weave 02:c5:00:91:95:a4 @ vethwepl6832: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl6832: missing
# weave 02:68:2f:29:fb:27 @ vethwepl6832: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl6832: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl6832: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl6832: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl6832: missing
# weave be:c3:40:d5:7a:98 @ vethwepl6832: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl6832: missing
ip link set vethwepl6832 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl7304: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl7304: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl7304: missing
# weave 02:c5:00:91:95:a4 @ vethwepl7304: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl7304: missing
# weave 02:68:2f:29:fb:27 @ vethwepl7304: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl7304: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl7304: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl7304: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl7304: missing
# weave be:c3:40:d5:7a:98 @ vethwepl7304: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl7304: missing
ip link set vethwepl7304 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl7566: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl7566: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl7566: missing
# weave 02:c5:00:91:95:a4 @ vethwepl7566: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl7566: missing
# weave 02:68:2f:29:fb:27 @ vethwepl7566: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl7566: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl7566: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl7566: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl7566: missing
# weave be:c3:40:d5:7a:98 @ vethwepl7566: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl7566: missing
ip link set vethwepl7566 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl8386: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl8386: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl8386: missing
# weave 02:c5:00:91:95:a4 @ vethwepl8386: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl8386: missing
# weave 02:68:2f:29:fb:27 @ vethwepl8386: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl8386: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl8386: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl8386: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl8386: missing
# weave be:c3:40:d5:7a:98 @ vethwepl8386: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl8386: missing
ip link set vethwepl8386 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl9143: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl9143: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl9143: missing
# weave 02:c5:00:91:95:a4 @ vethwepl9143: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl9143: missing
# weave 02:68:2f:29:fb:27 @ vethwepl9143: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl9143: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl9143: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl9143: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl9143: missing
# weave be:c3:40:d5:7a:98 @ vethwepl9143: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl9143: missing
ip link set vethwepl9143 nomaster
# weave e2:7f:bd:e3:db:d3 @ vethwepl9586: id=8dfc61bc31d8 ip=10.81.128.55/16
# weave e2:7f:bd:e3:db:d3 @ vethwepl9586: missing
# weave 06:fc:01:5e:b5:fa @ vethwepl9586: missing
# weave 02:c5:00:91:95:a4 @ vethwepl9586: id=725dedda4925 ip=10.81.128.108/16
# weave 02:c5:00:91:95:a4 @ vethwepl9586: missing
# weave 02:68:2f:29:fb:27 @ vethwepl9586: missing
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl9586: id=a6e282a7b820 ip=10.81.128.102/16
# weave 8a:cf:1a:e4:c9:c2 @ vethwepl9586: missing
# weave c6:5b:31:a0:77:a1 @ vethwepl9586: missing
# weave ba:ad:e6:6a:11:0f @ vethwepl9586: missing
# weave be:c3:40:d5:7a:98 @ vethwepl9586: id=1b527619f062 ip=10.81.128.31/16
# weave be:c3:40:d5:7a:98 @ vethwepl9586: missing
ip link set vethwepl9586 nomaster

arping output:
Host:
arping -I weave 10.81.128.20
ARPING 10.81.128.20 from 10.81.0.1 weave
Unicast reply from 10.81.128.20 [82:D0:28:6B:7B:42]  0.682ms
Unicast reply from 10.81.128.20 [06:FC:01:5E:B5:FA]  0.706ms
Unicast reply from 10.81.128.20 [FE:FA:0B:55:78:10]  0.720ms
Unicast reply from 10.81.128.20 [FE:FA:0B:55:78:10]  0.530ms

Container:
arping 10.81.128.20
ARPING 10.81.128.20
42 bytes from 82:d0:28:6b:7b:42 (10.81.128.20): index=0 time=5.955 msec
42 bytes from 06:fc:01:5e:b5:fa (10.81.128.20): index=1 time=6.010 msec
42 bytes from fe:fa:0b:55:78:10 (10.81.128.20): index=2 time=6.034 msec
42 bytes from 82:d0:28:6b:7b:42 (10.81.128.20): index=3 time=8.709 msec

Not 100% sure this is the same issue, was linked here by Kontena slack.

@panuhorsmalahti unfortunately we have two sets of symptoms in this issue; please can you open your own issue to avoid making things worse?

@panuhorsmalahti I read carefully through the output you supplied from weave-zombie-hunter.sh, and the scripts, and I cannot see how they fit.
The way I read the script, if it prints id=8dfc61bc31d8 ip=10.81.128.55/16 then it should not subsequently print missing for the same veth.  Yet most of your veths have both.
Also, it seems to be saying that every single one of the veths on your system is "nomaster".
Are you running the same scripts I am reading?

Created a new issue: https://github.com/weaveworks/weave/issues/2842

source: gharchive/issue

authors: SpComb Starefossen awh bboreham brb crockpotveggies jakolehm panuhorsmalahti rade

repo: weaveworks/weave

license_source: bigquery


text:
fix(generator): storybook v7 template lint error

Summary
Related Links

Checklist

[ ] I have added changeset via pnpm run change.
[ ] I have updated the documentation.
[ ] I have added tests to cover my changes.

!bench-framework

!bench-module

Why has it been added back again?

Why has it been added back again?

Not again, this was just fixed in inner code before.

license: MIT


text:
make @rspack/core as peerDep of @rspack/cli

as discussed in https://github.com/web-infra-dev/rspack/discussions/4632
Breaking Change
old users need to install @rspack/cli and @rspack/core together now

fixed in #4646

repo: web-infra-dev/rspack


text:
feat: tell the end developers and plugin developers whether their config/plugins are used by rspack

Summary

1. tell the end devs they are using rspack
for sharing configuration file between rspack and webpack.
for instance:
// rspack.config.js
module.exports = function(env) {
  /** align with webpack's WEBPACK_BUNDLE @{link https://github.com/webpack/webpack-cli/blob/eea6adf7d34dfbfd3b5b784ece4a4664834f5a6a/packages/webpack-cli/src/webpack-cli.ts#L2500-L2503} */
  const isRspack = env.RSPACK_BUNDLE;
  const config = {};
  if (isRspack) {
    config.experiments.rspackFuture = {
      newTreeShaking: true
    };
  }
  return config;
}

i'm also going to add WEBPACK_ prefixed builtin env in 0.5.0.
2. tell the plugin devs they are using rspack
the plugin dev can separately introduce different logics for rspack and webpack.
for instance:
const plugin = {
  apply(compiler) {
    const { isRspack } = compiler;
    if (isRspack) {
      // do something special
    }
  }
}

Test Plan

Require Documentation?

[x] No
[ ] Yes, the corresponding rspack-website PR is __

I personally may discourage this change, as we already have compiler.webpack.rspackVersion to determine in plugins.

I personally may discourage the second change, as we already have compiler.webpack.rspackVersion to determine in plugins.

Oh right. i'll drop the change later

I personally may discourage the second change, as we already have compiler.webpack.rspackVersion to determine in plugins.

Oh right. i'll drop the change later

done

MORE CONTEXT: https://webpack.js.org/api/cli/#env


text:
feat: use default allocator by default !macos !linux !windows

Summary

Checklist

[ ] Tests updated (or not required).
[ ] Documentation updated (or not required).

!bench

!bench

!bench

!bench

!bench

!bench


text:
fix(core): fix writeSearchIndex function use userConfig instead modifiedConfig

problem: dev command make search_index.json write to default outDir when outDir is set in plugin, when search trigger, dev server will halt because search_index.json not exists in final outDir.
Summary
Related Issue

Checklist

[ ] Tests updated (or not required).
[ ] Documentation updated (or not required).

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant liuwenzhuang

repo: web-infra-dev/rspress


text:
Document pain points setting up local development environment using Windows

As a contributor using a Windows machine,
I want to know what the pain points/gotchas are when setting up my dev environment,
So that I can more easily get setup on a windows machine
Description
As part of #435, we realised that our local development environment setup has not been made Windows compatible. We should ensure that contributors using Windows can easily work with bls-wallet. This issue is concerned with documenting pain points. A follow up issue(s) will be created to implement the needed changes.
Acceptance criteria:

List of pain points is documented (This may include errors encountered, setup required etc.)
In the form of either 1) A publicly available link e.g. hackmd note or notion page 2) The comment section of this issue

1] When I run ./setup with deno in normal windows terminal (not using wsl) it pops up with an error:

2]I was able to run the setup script when i switched to WSL terminal. Following are the steps which helped me to run the setup script:

I think while setting up local development a developer would require WSL installed on his windows system to run the ./setup script.
To run deno you need to install it seperately for WSL using curl -fsSL https://deno.land/x/install/install.sh | sh which requires an unzip package which can be installed using sudo apt install unzip
i ran into an error of could not get lock /var/lib/dpkg/lock-frontend while setting up unzip, which i debugged by referring to an youtube video
switched to node v16.0.0 using nvm use 16.0.0'
ran deno run --allow-read ./setup.ts command.

3]While running yarn start and yarn start-hardhat I bumped in an error of terminal not discovering the file

4] By using earlier versions of local development documentation I was able to :

run hardhat node
fund the deployer
deploy all the scripts

I used the prior commands to perform these tasks and not the one mentioned in point 3 as it would throw an error
5]while deploying i ran into an error of:

Which with prior discussions cleared that it was meant to be deleted and ran the deploy command which resulted in an error of  not able to find module:

To resolve this I had to clone the repo again and run through step 4. I did not encounter errors this time
6]Docker set up requires integration with WSL.

It can be setup using setup in setting of docker.
I personally am running in to some trouble which is related to .wslconfig in user directory.
I am trying to look deeper into it for now.

I would hit back If i am able to resolve it and would shout if I couldn't
Hope this helps!:)
Also i couldn't assign myself to the task as i don't have write permission to the project!

Awesome thanks @ri-dev-git
We're going to look into making our setup machine agnostic next week. The end result is if you can run docker successfully, things should just work.
In the meantime, I would make sure you can use docker on your machine with no problems. Will report back when we've got things set up. We've got a few things on atm, but looking to get this sorted over the next few weeks :)

Follow up issue #476

authors: JohnGuilding ri-dev-git


text:
Make available via Atom Package Manager

This package isn't available via the in 'Install' section in Settings - or via Command line with:
apm install atom-htmlizer
Can you update this package so it's Atom 1.0 compatible and available to download/install?

sure... i'll check it out. thanks for the heads up!

+1. Still can't find it.

authors: coliff joshbader vigo

repo: webBoxio/atom-htmlizer

license: mit


text:
Z-Targeting: Character Select Option is Not Visible

In Character Menu, Character select option is not visible
https://user-images.githubusercontent.com/104460803/174291224-b9bd223e-46e7-4223-8489-fd2e1d6d1c20.mp4

You need to zoom out.

I zoomed out but the issue is still there

You can solve this by pressing ctrl + -
We need to make the UI more responsive generally, but that's a different issue. Closing this one.

repo: webaverse/app


text:
App: Freezes when equipping items

After dragging an item from the inventory (i) to the slot, the app freezes.

This happens regardless of the inventory UI, I spawned a sword from prefabs list and equipped and it froze.

Thanks, for these cases a stack trace is most helpful:
rig-aux.js:334 Uncaught TypeError: Cannot read property 'bone' of undefined
    at RigAux.decapitate (rig-aux.js:334)
    at App.render (app.js:191)
    at animate (app.js:361)
    at onAnimationFrame (three.module.js:24228)
    at onAnimationFrame (three.module.js:12673)
decapitate @ rig-aux.js:334
render @ app.js:191
animate @ app.js:361
onAnimationFrame @ three.module.js:24228
onAnimationFrame @ three.module.js:12673
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675
requestAnimationFrame (async)
onAnimationFrame @ three.module.js:12675

I think it might be fixed now. There was a bug in the wearables components lookup.

It doesn't freeze anymore but wearables and pets don't attach and preview avatar doesn't show up.

I guess we need to wait until the new menu page is done on a few weeks.

Folding this into https://github.com/webaverse/app/issues/895

authors: avaer madjin


text:
feat : Add filebeat CRD and controller

Signed-off-by: disaster37 linuxworkgroup@hotmail.com

Fix enhance #26

repo: webcenter-fr/elasticsearch-operator


text:
Fix: Minor bug in writer.py opener missing self

###Description

webdataset/writer.py: Add self to opener call in ShardWriter

###Motivation

ShardWriter broken when using an opener

awesome sauce

Thanks.

authors: ModdingFox tmbdev

repo: webdataset/webdataset


text:
Make consistent header / page container styles

It seems like each page is doing it's own approach to the header.  We should find a way to make all pages have a uniform looking h1 header.  Also, each page should have a similar container, margin, padding.

Do you prefer making a header component or just apply the same styles to every page?

authors: FleetAdmiralJakob webdevcody

repo: webdevcody/survive-the-night-sim


text:
Deployment with AWS or GCC

Is there any documentation on about deployment on AWS or GCC?

There is currently a refactoring in work with new base images:
https://github.com/webdevops/php-docker-boilerplate/tree/feature/refactoring
This refactoring also supports deployment tasks (with ansible) or just copy your sourcode into your docker containers. There is already one cloud example.

authors: TheGent mblaschke


text:
Retry command as W3C when MicrosoftWebDriver returns Unknown Error

Proposed changes
This PR will fix https://github.com/webdriverio/webdriverio/issues/3143
MicrosoftWebdriver (which powers edge) will return back "Unknown Command" if it receives a JSON Wire Protocol command while running in W3C Mode (which is now default in recent Windows 10 Releases).
This PR will allow the "Unknown Error" error to be retried.
Types of changes

[x] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist

[x] I have read the CONTRIBUTING doc
[x] I have added tests that prove my fix is effective or that my feature works
[x] I have added necessary documentation (if appropriate)
[ ] I have proposed the same patch to the new v5 repository

Further comments

I don't believe this is necessary in v5, as I think v5 uses w3c commands by default
It would be really nice to refine the conditional to (psuedocode) if (isUnknownError(err) && Browser == "Edge"), but I'm not sure how to detect the browser in this piece of code

Reviewers: @christian-bromann

Happy to merge once, the CLA is signed.

authors: christian-bromann dylanlive


text:
Provided binary setting is ignored if versions.txt file exists

On the 2nd call / when the versions.txt file exists the provided binary settings gets overwritten/ignored/not used.
Imho line:
https://github.com/webdriverio-community/wdio-vscode-service/blob/54cb76ff746f01948dacca9cef8cd9209e827b42/src/launcher.ts#L165
should be changed e.g. to
cap[VSCODE_CAPABILITY_KEY].binary = cap[VSCODE_CAPABILITY_KEY].binary || await this._downloadVSCode(content[version]?.vscode as string)

@mbehr1 makes sense to me, mind raising a PR?

will do so!

@christian-bromann  see PR#38. Tried to follow same coding style.


text:
6 - shallow ref

// your answers

state.value = { count:2 }

repo: webfansplz/vuejs-challenges


text:
resolver instrumentation

Basically re-opening https://github.com/webonyx/graphql-php/issues/94 :grin:
I'm understanding I/we just need to wrap resolveOrError in a pluggable before/after hook?  Plus a small amount of spec work around promise/error handling.

One thing why this is problematic for me right now is that we may implement it in a different way comparing to the reference implementation, which will make further maintenance much harder (or will require breaking changes).
So I think it makes sense to wait until they resolve https://github.com/graphql/graphql-js/issues/284 and follow up after that.

Ah.  That issue is coming up on its two-year birthday 😢
Disappointing but understandable; if there's any way around being blocked by reference impl here, I'd be interested to hear solutions.

I think I've managed to implement this without framework changes by wrapping resolvers.  We have a place where we ensure singleton class instances (which is mandated by the framework, of course) and I can drop something like this in the pipe:
  /**
   * @param \GraphQL\Type\Definition\Type $instance The type instance
   *
   * @return Type
   */
  protected static function maybeInstallTelemetry($instance) {
    if (self::$telemetry && $instance instanceof ObjectType) {
      foreach ($instance->getFields() as $field) {
        $resolver = $field->resolveFn;
        // TODO maybe we should instrument the default resolver too?
        if ($resolver) {
          $field->resolveFn = function(...$args) use ($resolver) {
            list($beforeHook, $afterHook) = self::$telemetry;
            $beforeHook(...$args);
            $res = $resolver(...$args);
            $afterHook(...$args);
            return $res;
          };
        }
      }
    }
    return $instance;
  }

It works well enough for my needs, I think, though I haven't done much testing yet.  Is anyone else taking an approach like this?

Well, actually composing resolvers is a recommended way to do this right now. If you do this in a lazy type loader - it should be ok.
I prefer using class-level resolveField callback in types and don't use field-level resolvers. In this case, the number of wrapping operations is way lower. Other option would be to wrap all resolvers inside definitions (of course if you have full control over your types):
'myField' => [
    'type' => Type::string(),
    'resolve' => MyUtils::wrap(function() {
    })
]

As for default resolver - you have full access to it, so you can replace it with whatever you want.

I think Laravel is doing this is the way - every middleware is wrapping another one, so you can always make a wrapper around your resolvers to handle, for example EntityNotFound exceptions.
For my handy use-case was to do instanceof check of final resolver in order to throw UserNotAuthorized exception when resolver implements AuthorizedUserOnly interface.

Closing because no action is pending on this right now from our side. We'll get back to it as soon as graphql-js moves forward with logging support.

For anyone interested, there is another proposal on how to enable apollo tracing for any existing schema: see https://github.com/webonyx/graphql-php/issues/289#issuecomment-399633709 PRs are welcome!

authors: caseycs roippi vladar

repo: webonyx/graphql-php


text:
Create Deferred type classes

I have wrapped my Deferreds in 2 functions:
'resolve' => GraphQLProxy::deferredMany(ReservationPlayer::class, 'reservation_id'), # $root to many: $building->floors
'resolve' => GraphQLProxy::deferredOne(Resource::class, 'resource_id'), # $root to one: $building->reception

It's the only 2 I've needed so far, but I can imagine many more kinds of Deferred loading.
It'd be very nice to create a Deferred class, and use it to store the queue and resolver. So instead of a Deferred object with a closure that returns a closure etc, it's just a single object that contains everything (for that specific field).
In my case, that would be
'resolve' => new CustomDeferredMany(ReservationPlayer::class, 'reservation_id'),
'resolve' => new CustomDeferredOne(Resource::class, 'resource_id'),

The default/provided would be the same as currently:
'resolve' => new CallbackDeferred(function() {
  // Return closures in closures
});

No need for static magic, or closures in closures. All the logic in a nice class. With some refactoring, it could be backward compatible by making Deferred a specific of the (new) DeferredInterface.
I don't understand PHP Promises, so I can't make a PR, but I still wanted to mention it. There are very few Deferred usages, so it might be doable... Or maybe I'm talking nonsense. Let me know.
(Deferred might have few usages, but calling a field's resolver might have many.)

But can't you already do the same using __invoke for such classes? A resolver is basically any callable, so you can wrap it as you want. Or am I missing something?

If __invoke is good enough for the graphql lib, that might be good enough for me. That depends on how callability is checked everywhere. You know that, I haven't checked.
I'm gonna try it. Be right back.

Yes. That works perfectly! Thanks.

authors: rudiedirkx vladar


text:
suddenly the repo cannot load

On the latest version - it was working fine and now I get an error loading repo message..... Tried reinstalling.

This is the same underlying issue as https://github.com/RootMyTV/RootMyTV.github.io/issues/9 (LG broke SSL)

I also have this problem

This should be fixed now, webosbrew repo is now hosted behind cloudflare with their own certificates.

I am still having this issue, both homebrew channel failing to load repo and rootmy.tv complaining about SSL. I am on 6.00.25, 55B7D device. Is there any steps I can rake besides fully resetting my TV?

W17H (M16P) firmware 06.00.25 (webOS 3.9.0) is vulnerable to RootMyTV v1 and v2, so if you can get past the SSL issue it should work.
You can host RootMyTV on a local HTTP server (e.g., I've used python3 -m http.server) and then navigate to your local instance in the TV's browser. You could also use your PC's browser to view index.html locally (file:) and supply your TV's IP address (although I've never done that myself). By default it will try to get stage2.html from https://rootmy.tv, but you can edit the URL in index.html.
I believe com.webos.app.facebooklogin requires stage2.html to be served over HTTPS, but it's possible it uses a different cert store than the browser. You can change the priorities of the apps (com.webos.app.acrcard, com.webos.app.facebooklogin, com.webos.app.alibaba) so that a different one gets chosen. acrcard is apparently broken on 3.x, but it still may be worth a try. I do not believe alibaba is present on W17H.
Much of index.html is devoted to working around origin issues and establishing an SSAP connection. Instead of using it, you can also just connect to the TV using an SSAP client and send the SSAP request manually. The endpoint is always ssap://system.launcher/launch, and the payload will be:
{
"id":"<target app>",
"params":{"<param name>":"<stage2 URL>"}
}

Each target app has its own parameter name:

com.webos.app.facebooklogin: server
com.webos.app.acrcard: contentTarget
com.webos.app.alibaba: target
You can either try to use the RootMyTV hosted stage2.html URL (https://rootmy.tv/stage2.html) or host it yourself.

authors: DavidBuchanan314 Informatic Soukyuu cpetry spants throwaway96

repo: webosbrew/webos-homebrew-channel


text:
Update package.json

It has dependency of "postcss": "^8.4.29", which is <8.4.31 according to
https://github.com/advisories/GHSA-7fh5-64p2-3v2j

This PR contains a:

[x] bugfix
[ ] new feature
[ ] code refactor
[ ] test update
[ ] typo fix
[ ] metadata update

Motivation / Use-Case

Breaking Changes

Additional Info

You can update your deps locally, don't need to update them here, because we use ^ to specify version

repo: webpack-contrib/postcss-loader


text:
mime@1.3.6 is vulernable

Do you want to request a feature or report a bug?

bug
What is the current behavior?
mime dependency is at 1.3.6
If the current behavior is a bug, please provide the steps to reproduce.

What is the expected behavior?
mime should be 1.4.x
If this is a feature request, what is motivation or use case for changing the behavior?
Please mention other relevant information such as your webpack version, Node.js version and Operating System.
https://nodesecurity.io/advisories/535

https://github.com/webpack-contrib/url-loader/commit/ced5990b9fef7e1ccf71d69f26c527f8c0a3c87a fixes the dependency to allow for 1.4.x versions, so we really just need a release

The dependency uses ^ so within the semver minor/patch range it should install the latest available on a fresh install anyways, but will be released as soon as someone from the release team as time of course :)

I'm just saying a release is important now since there's a vulnerability

Yep, I understand  and we are aware, but it shouldn't be that urgent since ^ will likely pull mime v1.4.1 already, the dependency minimum should be set to v1.4.1 just in case nevertheless

Oh, I mean the last released version of this library didn't use ^. Usage of ^ was done in https://github.com/webpack-contrib/url-loader/commit/ced5990b9fef7e1ccf71d69f26c527f8c0a3c87a

It's out on the next dist-tag for the time being.

authors: d3viant0ne michael-ciniawsky ntucker

repo: webpack-contrib/url-loader


text:
Create source maps

It would be very helpful if there was some way to emit source maps for .less files.

:+1:
less.render already output source maps but I am not sure how to combine them with css-loader.
because I am not webpack expert I have dig into coffee-loader to figure out how he is passing source maps so I have tried to add
var map = JSON.parse(result.map);
map.sourceContent = [input];
cb(null, result.css, map);

to but no luck :unamused:
so it would be great if someone who know how to combine these things could help to figure this one out
also it would be useful if these will work with autoprefixer

I'm using webpack with LESS loader and autoprefixer and got working sourcemaps with the following loader config line:
test: /\.less$/,
loader: 'style-loader/useable!css-loader?sourceMap!autoprefixer-loader?browsers=last 2 version!less-loader?sourceMap=source-map-less-inline'

To get this working you need to make a change to style-loader and to less-loader. I didn't find the time yet to create a proper merge request.
in style loader: 'stylesheet/css' should be changed to 'text/css':
---node_modules/style-loader/addStyles.js
+++ node_modules/style-loader/addStyles.js
@@ -171,7 +171,7 @@
	if(sourceMap && typeof btoa === "function") {
		try {
			css += "\n/*# sourceMappingURL=data:application/json;base64," + btoa(JSON.stringify(sourceMap)) + " */";
-			css = "@import url(\"data:stylesheet/css;base64," + btoa(css) + "\")";
+			css = "@import url(\"data:text/css;base64," + btoa(css) + "\")";
		} catch(e) {}
	}

In less-loader the option to create sourcemaps should be passed to a sub-object with the key 'sourceMap'. The query paramaters are passed to the top level config. The code should be changed so that all sourcemap specific options are passed in the sourceMap object instead of the parent config.
To just get inline sourcemaps:
--- node_modules/less-loader/index.js
+++ node_modules/less-loader/index.js
@@ -21,7 +21,10 @@
 		filename: this.resource,
 		paths: [],
 		relativeUrls: true,
-		compress: !!this.minimize
+       compress: !!this.minimize,
+        sourceMap: {
+            sourceMapFileInline : true
+        }
 	};
 	var webpackPlugin = {
 		install: function(less, pluginManager) {

Note that these changes are only tested with the '/usable' feature from the style-loader. This is the mode where you can manually call .use() and .unuse() on the required less files.
Feel free to make these changes general and make proper merge requests for them.
Once you get this the sourcemaps are working but the file names are really long. To workaround this I used this change in style loader to split the path:
node_modules/style-loader/addStyles.js
var basedirectoryName = 'repoName';
    sourceMap.file = sourceMap.file.split(basedirectoryName).pop();
    for(var i = 0; i < sourceMap.sources.length; i++) {
        sourceMap.sources[i] = sourceMap.sources[i].split(basedirectoryName).pop();
    }

	if(sourceMap && typeof btoa === "function") {
		try {
			css += "\n/*# sourceMappingURL=data:application/json;base64," + btoa(JSON.stringify(sourceMap)) + " */";
			css = "@import url(\"data:text/css;base64," + btoa(css) + "\")";
		} catch(e) {}
	}

This is not good enough to be a pull request as it needs the basedirectoryName. But in that place something can be changed to get shorter/usable filenames.
Also note that once source-maps are enabled on the css loader you can no longer use import statements in you're css files. This is not supported in external stylesheets, and this seems the only mode that supports sourcemaps. This is only a problem for the import's that get not resolved before the browser context, so the imports that are replaced by less-loader or url-loader are working fine.

You can ignore my previous post and see an example at
https://github.com/3sv/webpack-less-autoprefixer-sourcemaps-demo
webpack + less + autoprefixer with source maps

thanks @3sv for help I was using old version of less :)

repo: webpack/less-loader


text:
add r/webpack page

An experiment for https://github.com/webpack/webpack/pull/13822#pullrequestreview-709439528

from: https://webpack.js.org/r/webpack/?option=output/filename
to: https://webpack.js.org/configuration/output/#outputfilename

Currently we can only make those redirections happen on client side as a single page application hosted on github pages won't support any server side redirects, i.e., urls of https://webpack.js.org/webpack-options/output/chunk-load-timeout type won't work unless we generate every intermediate page for them.
Example: https://webpack-js-org-git-fork-chenxsan-feature-ha-97c6dc-webpack-docs.vercel.app/r/webpack/?option=output/filename

I'm afraid it won't work as the documents don't share a common pattern.
E.g.,

/configuration/module/#modulegenerator
/configuration/module/#rulelayer

This pull request would work only for the first pattern. And there could be other patterns besides the aforementioned two.


text:
Webpack 2: TypeError: _webpack2.default.optimize.OccurenceOrderPlugin is not a function

I'm using webpack with an express server and the webpack-hot-middleware, while I'm getting following error on starting:
> babel-node server

/Users/Glenn/Projects/react-boilerplate/webpack.config.js:28
  plugins: [new _webpack2.default.optimize.OccurenceOrderPlugin(), new _webpack2.default.HotModuleReplacementPlugin(), new _webpack2.default.NoErrorsPlugin()]
            ^

TypeError: _webpack2.default.optimize.OccurenceOrderPlugin is not a function
    at Object.<anonymous> (webpack.config.js:24:5)
    at Module._compile (module.js:413:34)
    at loader (/Users/Glenn/Projects/react-boilerplate/node_modules/babel-register/lib/node.js:130:5)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/Glenn/Projects/react-boilerplate/node_modules/babel-register/lib/node.js:140:7)
    at Module.load (module.js:357:32)
    at Function.Module._load (module.js:314:12)
    at Module.require (module.js:367:17)
    at require (internal/module.js:16:19)
    at Object.<anonymous> (/Users/Glenn/Projects/react-boilerplate/server.js:23:17)
    at Module._compile (module.js:413:34)

npm ERR! Darwin 15.3.0
npm ERR! argv "/usr/local/Cellar/node/5.5.0/bin/node" "/usr/local/bin/npm" "start"
npm ERR! node v5.5.0
npm ERR! npm  v3.5.3
npm ERR! code ELIFECYCLE
npm ERR! react-boilerplate@1.0.0 start: `babel-node server`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the react-boilerplate@1.0.0 start script 'babel-node server'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     babel-node server
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/Glenn/Projects/react-boilerplate/npm-debug.log

I'm using babel-node as I am using ES6 imports/exports on my server configuration.
The plugins in the webpack config looks like this:
...
  plugins: [
    new webpack.optimize.OccurenceOrderPlugin(),
    new webpack.HotModuleReplacementPlugin(),
    new webpack.NoErrorsPlugin()
  ]
...

Any clues?

OccurenceOrderPlugin has been renamed to OccurrenceOrderPlugin.

Works perfect now, thanks!

FYI to anyone else who reads this.  The OccurrenceOrderPlugin is no longer needed:
https://gist.github.com/sokra/27b24881210b56bbaff7#occurrence-order

@glennreyes nice

I've got the same problem but I don't know how the document may be configured, If anybody can write an example I really appreciate it. Below the code I'm using, thanks:
`var debug = process.env.NODE_ENV !== "production";
var webpack = require('webpack');
module.exports = {
context: __dirname,
devtool: debug ? "inline-sourcemap" : null,
entry: "./scripts.js",
output: {
path: __dirname + "/js",
filename: "scripts.min.js"
},
plugins: debug ? [] : [
new webpack.optimize.DedupePlugin(),
new webpack.optimize.OccurenceOrderPlugin(),
new webpack.optimize.UglifyJsPlugin({ mangle: false, sourcemap: false }),
],
};
`
And this's the bug:
TypeError: webpack.optimize.OccurenceOrderPlugin is not a function

@mrwildok If you are using webpack 2, you should drop new webpack.optimize.OccurenceOrderPlugin().

Also you don't necessarily need to mess with the configuration, you can just run webpack -p and webpack will do the magic for you as clearly stated in the documentation.

Current setup for Webpack 2.
var debug = process.env.NODE_ENV !== "production";
var webpack = require('webpack');
module.exports = {
context: __dirname,
devtool: debug ? "inline-sourcemap" : false,
entry: "./js/scripts.js",
output: {
path: __dirname + "/js",
filename: "scripts.min.js"
},
plugins: debug ? [] : [
new webpack.optimize.OccurrenceOrderPlugin(),
new webpack.optimize.UglifyJsPlugin({ mangle: false, sourcemap: false }),
],
};
Why? Because this tutorial is on Webpack 1. We just need to tweak slightly to make it work with Webpack 2.
Changes

debug ? "inline-sourcemap" : false,    <-- used to be null
removed dedupe plugin - it's no longer needed.

authors: bebraw ctrlplusb eshwarenm glennreyes handycode manix marksamman mrwildok

repo: webpack/webpack


text:
Watch for config changes

I'm submitting a feature request
Webpack version:
2.x
Please tell us about your environment:
OSX 10.x
Current behavior:
I'm not sure if this was discussed before, but it's one of the pain point for me in webpack workflow.
When config / config's dep is updated — hot reloadable server (or watch mode) must be restarted manually. Usually this hot reloadable server is not stand-alone process, but part of the bigger task or even lives inside docker container. And in case of config related change — the only way to pick this up is to restart everything.
Expected/desired behavior:
It'd be cool if webpack could track such changes and rebuild everything from scratch w/o killing current process.
What is the motivation / use case for changing the behavior?
It'll make easier:

work on webpack config setup
work w/ loader's configs, eg postcss plugin's options (js vars etc)

Unfortunately, a webpack config file is not necessarily pure. Automatically reloading impure config files can result in pain and suffering.
Plugins may also want to run at hook points that happen before the watch-run loop, so if those plugins need reloading, they will never be called again, unless webpack destroys and re-creates the compiler every time.
Even if you write things as "pure"ly as possible for your export, if you require anything at all besides require('webpack') inside the config, it's no longer reloadable.

@Kovensky Agreed. The case when webpack destroys and recreates everything from scratch on change in config / its dep is the behaviour that solves all the issues w/ min pain and this is what I meant initially. I guess this part was confusing:
... and reload config in the same manner as it tracks app deps in watch mode.

Not in the same manner, but just tracks changes and rebuilds everything from scratch. I'll update the issue.
Personally I don't care if it'll take time, restarting global task or docker will take even more time. If I changed something in config — well it means that I want to see the result of this change and next thing that I'll do is restart, so it might make sense to do this internally.

FWIW, it's fairly simple to patch something together yourself using Chokidar. Here's my go at it. That's for webpack 1 so it webpack-dev-server may need a little patching to work around a bug, but it works.

@bebraw that would deal with the webpack.config.js itself, but the wishlist includes the dependencies

@Kovensky Yeah, that's a harder problem for sure. npm-install-webpack-plugin might be worth studying in detail.

The problem with configuration dependencies is that some of those are implicit (think loaders). It would be an easier problem with explicit imports. Now it's going to get kind of tricky to figure out what changed if I'm understanding right.

Another workaround, using nodemon, is described in https://github.com/webpack/webpack-dev-server/issues/440#issuecomment-205757892

The nodemon trick works great. You can make it work with webpack 2 env like this ´  "start": "nodemon --watch webpack.config.js --exec "webpack-dev-server --env development"",`.
The browser will still cache some bits like html-webpack-plugin title, but it works well enough for it to be worthwhile.
I guess ideally WDS should force a hard refresh if this functionality is implemented there.

Moved to https://github.com/webpack/webpack-cli/issues/15.

I'm curious why this was moved to webpack/webpack-cli#15
Isn't in the right place and it should actually be a part of webpack or maybe even webpack/watchpack?
This idea has been request in multiple threads and just tracking down a solution is like Alice falling down the rabbit hole into wonderland. It appears to eventually have been added to the webpack-cli but then removed as of a few weeks ago. Then re-added, but with the wrong implementation spec so that it no longer accomplished the same thing as the nodemon hack.
I am trying to implement the nodemon hack with a Phoenix app... wish me luck.

@owenstrevor Webpack doesn't come with a cli as it was separated from the core. That said, you could be right in that it's a core feature (esp. watchpack) and likely it requires core level tweaks in webpack itself (reactive config). It could be a potentially big change. That's why the external hacks (i.e. nodemon) as they don't have to change webpack itself fundamentally.

Thanks for the quick reply @bebraw.
I totally understand what you are saying, and how it could be a potentially big change. My confusion is more around how the request got moved around from one place to another, to an absurd degree.
Took me a little while but I got it nodemon working and it does the job well. Thanks again.

authors: Kovensky alexfedoseev bebraw jzaefferer owenstrevor


text:
FR: Additional substitution variable for "project path"

Do you want to request a feature or report a bug?
feature
What is the expected behavior?
see: https://webpack.js.org/configuration/output/#output-filename
There are many variables you can use, additionally it were nice there were a variable for the absolute path to the FOLDER of the used web pack config. like: [projectpath]
If no config is given (called webpack programatically) then an error should be thrown.
If a javascript file is given (which generates the config), the variable is related to this js file's folder.
Other ideas: [context] - to just substitute the path of the given context path. If context is not given, throw an exception.

HOWEVER, currently it vary very which of the following syntax you can use on the different config properties, it should be more consistent. So in most cases the [projectpath]/[context] variable can be spared.
/absolute/path
./relative/path
without/prefix/path

I think every type should be allowed whenever it's possible.
If this is a feature request, what is motivation or use case for changing the behavior?

A further step to write plain json webpack configuration.
Don't require to use the path module all the time.

output.filename doesn't accept absolute paths. where do you want to use [context]?


text:
Server-side hot reload not working for Node 11.x

Bug report

What is the current behavior?
On Node.js 11.x, server-side hot reload does not work.
I tracked it down to the function hotDownloadManifest in lib/node/NodeMainTemplate.runtime.js, which is always returning undefined. It's the require statement that's failing - even though the manifest file $hotMainFilename$ exists.
If the current behavior is a bug, please provide the steps to reproduce.
On Node.js 11.x, server-side bundle with HotModuleReplacementPlugin, with entry webpack/hot/poll.

What is the expected behavior?
The function hotDownloadManifest in lib/node/NodeMainTemplate.runtime.js should return the update data from the manifest, specifically this part:
require("./" + $hotMainFilename$)

On Node.js 10.x, the exact same setup works correctly. That hints at the issue being not in Webpack, but Node itself..

Other relevant information:
webpack version: 4.29.6
Node.js version: 11.13.0
Operating System: macOS 10.14.3
Additional tools: yarn

Please submit a reproducible repository.

OK, will try to set up a minimal example demonstrating the issue.

Here's an example: https://github.com/eliot-akira/webpack-server-side-hot-reload-issue/
I use n to switch between Node versions. I specifically confirmed with Node.js 10.15.3 and 11.13.0. With the former, the above repo has working hot reload; with the latter, it doesn't.

I confirmed this issue only Node11.
{ Error: Cannot find module './f7f5c34b7aecf12db41d.hot-update.json'
    at Function.Module._resolveFilename (internal/modules/cjs/loader.js:649:15)
    at Function.Module._load (internal/modules/cjs/loader.js:575:25)
    at Module.require (internal/modules/cjs/loader.js:705:19)
    at require (internal/modules/cjs/helpers.js:14:16)
    at hotDownloadManifest (/Users/xxx/Desktop/webpack-server-side-hot-reload-issue/build/server.js:11:26)
    at Object.hotCheck [as check] (/Users/xxx/Desktop/webpack-server-side-hot-reload-issue/build/server.js:203:19)
    at Timeout.checkForUpdate [as _onTimeout] (webpack:///(webpack)/hot/poll.js?:13:6)
    at listOnTimeout (timers.js:327:15)
    at processTimers (timers.js:271:5) code: 'MODULE_NOT_FOUND' }

With the test repo I get the same behaviour that @eliot-akira does - in node.js 11.x, server-side hot reload does not work, in 10.x it does. I get no errors.

As per #9015, this should be fixed in the next Node.js 11 release. I searched their issues and pulls but couldn't find the relevant commit. I'll keep this issue open and note when the fix is confirmed.

The issue is solved on Node 12.x.

authors: eliot-akira hiroppy nikparo