Antrea interfaces are lost upon OS reboot

Describe what you are trying to do
Install latest Antrea version w/K8s (kubeadm) on a single node running on VMware Photon OS
Software Versions
Antrea: v1.2.0
Kubernetes: v1.20.2
OS: Photon OS 4.0 (1526e30ba)
Observed Behavior
Everything is configured correctly upon first boot and setting up our application. However, after an OS reboot, all Antrea interfaces are lost
Here is the output for the interfaces before the reboot:
ifconfig
activato-df5b3e Link encap:Ethernet  HWaddr 16:74:b1:97:05:30
          inet6 addr: fe80::700c:81ff:fefc:640e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:896 errors:0 dropped:0 overruns:0 frame:0
          TX packets:981 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:73702 (73.7 KB)  TX bytes:426855 (426.8 KB)

antrea-gw0 Link encap:Ethernet  HWaddr 16:91:23:20:09:32
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::1491:23ff:fe20:932/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:67417 errors:0 dropped:0 overruns:0 frame:0
          TX packets:77867 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:11927615 (11.9 MB)  TX bytes:33683710 (33.6 MB)

autoscal-19e274 Link encap:Ethernet  HWaddr 6a:45:89:6a:0c:f5
          inet6 addr: fe80::40b9:d3ff:fe2c:d9da/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:8039 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9873 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:864572 (864.5 KB)  TX bytes:6985122 (6.9 MB)

cadvisor-01dd4a Link encap:Ethernet  HWaddr 42:75:5a:06:e9:e7
          inet6 addr: fe80::8a2:eaff:fe9f:4509/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:12 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:126 (126.0 B)  TX bytes:796 (796.0 B)

contour--204261 Link encap:Ethernet  HWaddr 32:e5:bd:27:ef:7c
          inet6 addr: fe80::1c0e:efff:fe59:ce82/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:1859 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2009 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:281622 (281.6 KB)  TX bytes:1370169 (1.3 MB)

contour--0078ed Link encap:Ethernet  HWaddr 32:99:0e:d2:66:59
          inet6 addr: fe80::b8a3:99ff:fe86:807b/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:1167 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1283 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:128976 (128.9 KB)  TX bytes:1121103 (1.1 MB)

contour--70d68b Link encap:Ethernet  HWaddr 1e:6f:ea:f8:33:99
          inet6 addr: fe80::b0b0:dcff:fedb:efd6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:2030 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2129 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:275429 (275.4 KB)  TX bytes:836719 (836.7 KB)

contour--e6d623 Link encap:Ethernet  HWaddr de:76:f4:97:88:b5
          inet6 addr: fe80::6404:92ff:fefa:6bfd/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:2048 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2167 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:289204 (289.2 KB)  TX bytes:858615 (858.6 KB)

contour--f475c3 Link encap:Ethernet  HWaddr ee:32:fb:f7:6c:ce
          inet6 addr: fe80::4400:78ff:fe28:de75/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:1068 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:95577 (95.5 KB)  TX bytes:662702 (662.7 KB)

controll-b53b15 Link encap:Ethernet  HWaddr b6:f3:3b:b6:e3:e2
          inet6 addr: fe80::7c85:dbff:feeb:c7cc/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:7769 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9496 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1597305 (1.5 MB)  TX bytes:3651252 (3.6 MB)

coredns--93cd05 Link encap:Ethernet  HWaddr 56:c4:5b:d6:66:2e
          inet6 addr: fe80::7c43:d1ff:fe2a:5ed9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:1092 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1237 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:136607 (136.6 KB)  TX bytes:283212 (283.2 KB)

coredns--dc8a4f Link encap:Ethernet  HWaddr 6a:51:04:3c:74:76
          inet6 addr: fe80::e820:9ff:fe28:7c4f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:1030 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1203 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:127635 (127.6 KB)  TX bytes:277336 (277.3 KB)

default--d2d1af Link encap:Ethernet  HWaddr ce:78:e2:0b:66:33
          inet6 addr: fe80::cc78:e2ff:fe0b:6633/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:470 errors:0 dropped:0 overruns:0 frame:0
          TX packets:396 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:152725 (152.7 KB)  TX bytes:133244 (133.2 KB)

docker0   Link encap:Ethernet  HWaddr 02:42:ba:f8:4f:67
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

envoy-dn-52e6e3 Link encap:Ethernet  HWaddr 46:83:14:5d:1a:b1
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::4483:14ff:fe5d:1ab1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:653 errors:0 dropped:0 overruns:0 frame:0
          TX packets:909 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:133394 (133.3 KB)  TX bytes:88295 (88.2 KB)

eth0      Link encap:Ethernet  HWaddr 00:50:56:a9:bc:ed
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::250:56ff:fea9:bced/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1647 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1148 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:340365 (340.3 KB)  TX bytes:292720 (292.7 KB)

eventing-34764c Link encap:Ethernet  HWaddr ea:c5:e5:28:1b:12
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::cca9:4eff:feba:54a2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:12828 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15555 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:3300629 (3.3 MB)  TX bytes:5111440 (5.1 MB)

eventing-e2eb71 Link encap:Ethernet  HWaddr ce:4d:42:8a:de:be
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::b853:9cff:fecd:3879/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:7762 errors:0 dropped:0 overruns:0 frame:0
          TX packets:9500 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:1739119 (1.7 MB)  TX bytes:5508267 (5.5 MB)

genev_sys_6081 Link encap:Ethernet  HWaddr fe:00:53:46:bc:fb
          inet6 addr: fe80::3cda:aff:fee5:bc58/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:65000  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:12 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback
          inet addr:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:302023 errors:0 dropped:0 overruns:0 frame:0
          TX packets:302023 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:120409132 (120.4 MB)  TX bytes:120409132 (120.4 MB)

local-pa-9f8672 Link encap:Ethernet  HWaddr 2e:16:d8:54:7b:1c
          inet6 addr: fe80::4071:d2ff:fe39:b282/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:1302 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1379 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:248350 (248.3 KB)  TX bytes:448298 (448.2 KB)

rabbitmq-a3f41e Link encap:Ethernet  HWaddr 06:f4:4a:de:fd:b6
          inet6 addr: fe80::8a0:1ff:feab:daf1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:3560 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3761 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:655919 (655.9 KB)  TX bytes:1668996 (1.6 MB)

rabbitmq-c1e836 Link encap:Ethernet  HWaddr 4a:f0:b6:4c:55:b4
          inet6 addr: fe80::1c8d:f3ff:fe78:706/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:3561 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3535 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:598318 (598.3 KB)  TX bytes:1553982 (1.5 MB)

sockeye--9d5d85 Link encap:Ethernet  HWaddr 52:69:da:b0:c0:1e
          inet6 addr: fe80::5069:daff:feb0:c01e/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:206 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:14492 (14.4 KB)  TX bytes:116838 (116.8 KB)

sockeye--d4aa95 Link encap:Ethernet  HWaddr 0a:a0:63:d2:70:f8
          inet6 addr: fe80::8a0:63ff:fed2:70f8/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:398 errors:0 dropped:0 overruns:0 frame:0
          TX packets:344 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:133577 (133.5 KB)  TX bytes:149324 (149.3 KB)

tinywww--d83d0f Link encap:Ethernet  HWaddr 16:f2:92:b2:60:f3
          inet6 addr: fe80::bc9a:3dff:fea3:b2af/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:3 errors:0 dropped:0 overruns:0 frame:0
          TX packets:18 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:126 (126.0 B)  TX bytes:1048 (1.0 KB)

veba-rab-f5a62b Link encap:Ethernet  HWaddr ae:ff:ed:af:8b:9d
          inet6 addr: fe80::ac29:ccff:fed1:60d7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:938 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1175 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:207547 (207.5 KB)  TX bytes:220264 (220.2 KB)

veba-ui--a1b58e Link encap:Ethernet  HWaddr 5a:32:98:9d:2e:9a
          inet6 addr: fe80::fc69:2aff:fe4e:809c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:11 errors:0 dropped:0 overruns:0 frame:0
          TX packets:20 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:784 (784.0 B)  TX bytes:1808 (1.8 KB)

vmware-e-310b46 Link encap:Ethernet  HWaddr 72:8b:14:7f:2a:6a
          inet6 addr: fe80::5469:43ff:fe44:5155/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:719 errors:0 dropped:0 overruns:0 frame:0
          TX packets:634 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:212561 (212.5 KB)  TX bytes:241644 (241.6 KB)

webhook--608e69 Link encap:Ethernet  HWaddr 42:1d:47:46:b3:e9
          inet6 addr: fe80::5c88:e0ff:fe5e:7b1f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1450  Metric:1
          RX packets:12017 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14678 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:2497766 (2.4 MB)  TX bytes:2845078 (2.8 MB)

Here is the output for the interfaces after to reboot:
ifconfig
docker0   Link encap:Ethernet  HWaddr 02:42:55:d6:1e:93
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:50:56:a9:bc:ed
          inet addr:<IP_ADDRESS>  Bcast:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: fe80::250:56ff:fea9:bced/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:90 errors:0 dropped:0 overruns:0 frame:0
          TX packets:59 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:9718 (9.7 KB)  TX bytes:7607 (7.6 KB)

lo        Link encap:Local Loopback
          inet addr:<IP_ADDRESS>  Mask:<IP_ADDRESS>
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:16 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:800 (800.0 B)  TX bytes:800 (800.0 B)

Expected Behavior
All Antrea interfaces are preserved and functional
Additional Info
In /var/log/antrea/openvswitch/ovs-vswitchd.log, before 2021-08-01T13:06:20.475Z you can see entries but after reboot, the interfaces are never re-created
2021-08-01T12:58:47.495Z|00001|vlog|INFO|opened log file /var/log/openvswitch/ovs-vswitchd.log
2021-08-01T12:58:47.506Z|00002|ovs_numa|INFO|Discovered 4 CPU cores on NUMA node 0
2021-08-01T12:58:47.506Z|00003|ovs_numa|INFO|Discovered 1 NUMA nodes and 4 CPU cores
2021-08-01T12:58:47.506Z|00004|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connecting...
2021-08-01T12:58:47.506Z|00005|netlink_socket|INFO|netlink: could not enable listening to all nsid (Operation not permitted)
2021-08-01T12:58:47.506Z|00006|reconnect|INFO|unix:/var/run/openvswitch/db.sock: connected
2021-08-01T12:58:47.511Z|00007|bridge|INFO|ovs-vswitchd (Open vSwitch) 2.14.0
2021-08-01T12:58:48.389Z|00008|ofproto_dpif|INFO|system@ovs-system: Datapath supports recirculation
2021-08-01T12:58:48.389Z|00009|ofproto_dpif|INFO|system@ovs-system: VLAN header stack length probed as 2
2021-08-01T12:58:48.389Z|00010|ofproto_dpif|INFO|system@ovs-system: MPLS label stack length probed as 3
2021-08-01T12:58:48.389Z|00011|ofproto_dpif|INFO|system@ovs-system: Datapath supports truncate action
2021-08-01T12:58:48.389Z|00012|ofproto_dpif|INFO|system@ovs-system: Datapath supports unique flow ids
2021-08-01T12:58:48.389Z|00013|ofproto_dpif|INFO|system@ovs-system: Datapath supports clone action
2021-08-01T12:58:48.389Z|00014|ofproto_dpif|INFO|system@ovs-system: Max sample nesting level probed as 10
2021-08-01T12:58:48.389Z|00015|ofproto_dpif|INFO|system@ovs-system: Datapath supports eventmask in conntrack action
2021-08-01T12:58:48.389Z|00016|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_clear action
2021-08-01T12:58:48.389Z|00017|ofproto_dpif|INFO|system@ovs-system: Max dp_hash algorithm probed to be 0
2021-08-01T12:58:48.389Z|00018|ofproto_dpif|INFO|system@ovs-system: Datapath supports check_pkt_len action
2021-08-01T12:58:48.389Z|00019|ofproto_dpif|INFO|system@ovs-system: Datapath supports timeout policy in conntrack action
2021-08-01T12:58:48.389Z|00020|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_state
2021-08-01T12:58:48.389Z|00021|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_zone
2021-08-01T12:58:48.389Z|00022|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_mark
2021-08-01T12:58:48.389Z|00023|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_label
2021-08-01T12:58:48.390Z|00024|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_state_nat
2021-08-01T12:58:48.390Z|00025|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_orig_tuple
2021-08-01T12:58:48.390Z|00026|ofproto_dpif|INFO|system@ovs-system: Datapath supports ct_orig_tuple6
2021-08-01T12:58:48.390Z|00027|ofproto_dpif|INFO|system@ovs-system: Datapath does not support IPv6 ND Extensions
2021-08-01T12:58:48.393Z|00028|bridge|INFO|bridge br-int: using datapath ID 00004e6c644b774b
2021-08-01T12:58:48.394Z|00029|connmgr|INFO|br-int: added service controller "punix:/var/run/openvswitch/br-int.mgmt"
2021-08-01T12:58:48.403Z|00030|bridge|INFO|bridge br-int: added interface antrea-tun0 on port 1
2021-08-01T12:58:48.406Z|00031|netdev|WARN|failed to set MTU for network device antrea-gw0: No such device
2021-08-01T12:58:48.407Z|00032|bridge|INFO|bridge br-int: added interface antrea-gw0 on port 2
2021-08-01T12:58:53.593Z|00033|bridge|INFO|bridge br-int: added interface local-pa-9f8672 on port 3
2021-08-01T12:58:53.628Z|00034|bridge|INFO|bridge br-int: added interface coredns--dc8a4f on port 4
2021-08-01T12:58:53.670Z|00035|bridge|INFO|bridge br-int: added interface webhook--608e69 on port 5
2021-08-01T12:58:53.772Z|00036|bridge|INFO|bridge br-int: added interface controll-b53b15 on port 6
2021-08-01T12:58:53.819Z|00037|bridge|INFO|bridge br-int: added interface coredns--93cd05 on port 7
2021-08-01T12:58:53.953Z|00038|bridge|INFO|bridge br-int: added interface autoscal-19e274 on port 8
2021-08-01T12:58:54.063Z|00039|bridge|INFO|bridge br-int: added interface activato-df5b3e on port 9
2021-08-01T12:58:57.512Z|00040|memory|INFO|56588 kB peak resident set size after 10.0 seconds
2021-08-01T12:58:57.512Z|00041|memory|INFO|handlers:2 ofconns:1 ports:9 revalidators:2 rules:103 udpif keys:100
2021-08-01T12:59:00.413Z|00042|connmgr|INFO|br-int<->unix#0: 125 flow_mods in the 8 s starting 10 s ago (124 adds, 1 deletes)
2021-08-01T12:59:09.401Z|00043|bridge|INFO|bridge br-int: added interface contour--2ddcb5 on port 10
2021-08-01T12:59:09.962Z|00044|bridge|INFO|bridge br-int: added interface contour--f959f3 on port 11
2021-08-01T12:59:10.356Z|00045|bridge|INFO|bridge br-int: added interface contour--204261 on port 12
2021-08-01T12:59:12.149Z|00046|bridge|INFO|bridge br-int: deleted interface contour--2ddcb5 on port 10
2021-08-01T12:59:12.997Z|00047|bridge|INFO|bridge br-int: added interface contour--e6d623 on port 13
2021-08-01T12:59:13.075Z|00048|bridge|INFO|bridge br-int: added interface contour--0078ed on port 14
2021-08-01T12:59:14.178Z|00049|bridge|INFO|bridge br-int: added interface envoy-dn-52e6e3 on port 15
2021-08-01T12:59:14.469Z|00050|bridge|INFO|bridge br-int: deleted interface contour--f959f3 on port 11
2021-08-01T12:59:17.461Z|00051|bridge|INFO|bridge br-int: added interface contour--70d68b on port 16
2021-08-01T12:59:17.705Z|00052|bridge|INFO|bridge br-int: added interface contour--f475c3 on port 17
2021-08-01T12:59:40.531Z|00053|bridge|INFO|bridge br-int: added interface eventing-e2eb71 on port 18
2021-08-01T12:59:40.553Z|00054|bridge|INFO|bridge br-int: added interface eventing-34764c on port 19
2021-08-01T12:59:50.474Z|00055|bridge|INFO|bridge br-int: added interface rabbitmq-a3f41e on port 20
2021-08-01T12:59:50.983Z|00056|bridge|INFO|bridge br-int: added interface rabbitmq-c1e836 on port 21
2021-08-01T12:59:52.403Z|00057|bridge|INFO|bridge br-int: added interface sockeye--9d5d85 on port 22
2021-08-01T12:59:54.558Z|00058|bridge|INFO|bridge br-int: added interface vmware-e-310b46 on port 23
2021-08-01T12:59:54.853Z|00059|bridge|INFO|bridge br-int: added interface helper-p-c8c285 on port 24
2021-08-01T12:59:55.605Z|00060|bridge|INFO|bridge br-int: deleted interface helper-p-c8c285 on port 24
2021-08-01T12:59:57.750Z|00061|bridge|INFO|bridge br-int: added interface veba-rab-f5a62b on port 25
2021-08-01T13:00:00.414Z|00062|connmgr|INFO|br-int<->unix#0: 151 flow_mods in the 57 s starting 59 s ago (136 adds, 15 deletes)
2021-08-01T13:00:29.387Z|00063|bridge|INFO|bridge br-int: added interface default--d2d1af on port 26
2021-08-01T13:00:31.119Z|00064|bridge|INFO|bridge br-int: added interface sockeye--d4aa95 on port 27
2021-08-01T13:00:39.087Z|00065|bridge|INFO|bridge br-int: added interface tinywww--d83d0f on port 28
2021-08-01T13:00:40.908Z|00066|bridge|INFO|bridge br-int: added interface veba-ui--a1b58e on port 29
2021-08-01T13:00:41.743Z|00067|bridge|INFO|bridge br-int: added interface cadvisor-01dd4a on port 30
2021-08-01T13:01:00.414Z|00068|connmgr|INFO|br-int<->unix#0: 49 flow_mods in the 25 s starting 42 s ago (49 adds)
2021-08-01T13:06:20.475Z|00069|bridge|INFO|bridge br-int: deleted interface sockeye--9d5d85 on port 22
2021-08-01T13:06:20.475Z|00070|bridge|INFO|bridge br-int: deleted interface cadvisor-01dd4a on port 30
2021-08-01T13:06:20.475Z|00071|bridge|INFO|bridge br-int: deleted interface vmware-e-310b46 on port 23
2021-08-01T13:06:20.475Z|00072|bridge|INFO|bridge br-int: deleted interface contour--204261 on port 12
2021-08-01T13:06:20.475Z|00073|bridge|INFO|bridge br-int: deleted interface antrea-tun0 on port 1
2021-08-01T13:06:20.475Z|00074|bridge|INFO|bridge br-int: deleted interface contour--e6d623 on port 13
2021-08-01T13:06:20.475Z|00075|bridge|INFO|bridge br-int: deleted interface rabbitmq-c1e836 on port 21
2021-08-01T13:06:20.475Z|00076|bridge|INFO|bridge br-int: deleted interface activato-df5b3e on port 9
2021-08-01T13:06:20.475Z|00077|bridge|INFO|bridge br-int: deleted interface tinywww--d83d0f on port 28
2021-08-01T13:06:20.475Z|00078|bridge|INFO|bridge br-int: deleted interface coredns--dc8a4f on port 4
2021-08-01T13:06:20.475Z|00079|bridge|INFO|bridge br-int: deleted interface veba-rab-f5a62b on port 25
2021-08-01T13:06:20.475Z|00080|bridge|INFO|bridge br-int: deleted interface contour--f475c3 on port 17
2021-08-01T13:06:20.476Z|00081|bridge|INFO|bridge br-int: deleted interface sockeye--d4aa95 on port 27
2021-08-01T13:06:20.476Z|00082|bridge|INFO|bridge br-int: deleted interface antrea-gw0 on port 2
2021-08-01T13:06:20.476Z|00083|bridge|INFO|bridge br-int: deleted interface rabbitmq-a3f41e on port 20
2021-08-01T13:06:20.476Z|00084|bridge|INFO|bridge br-int: deleted interface default--d2d1af on port 26
2021-08-01T13:06:20.476Z|00085|bridge|INFO|bridge br-int: deleted interface eventing-34764c on port 19
2021-08-01T13:06:20.476Z|00086|bridge|INFO|bridge br-int: deleted interface controll-b53b15 on port 6
2021-08-01T13:06:20.476Z|00087|bridge|INFO|bridge br-int: deleted interface webhook--608e69 on port 5
2021-08-01T13:06:20.476Z|00088|bridge|INFO|bridge br-int: deleted interface veba-ui--a1b58e on port 29
2021-08-01T13:06:20.476Z|00089|bridge|INFO|bridge br-int: deleted interface local-pa-9f8672 on port 3
2021-08-01T13:06:20.476Z|00090|bridge|INFO|bridge br-int: deleted interface envoy-dn-52e6e3 on port 15
2021-08-01T13:06:20.476Z|00091|bridge|INFO|bridge br-int: deleted interface eventing-e2eb71 on port 18
2021-08-01T13:06:20.476Z|00092|bridge|INFO|bridge br-int: deleted interface contour--70d68b on port 16
2021-08-01T13:06:20.476Z|00093|bridge|INFO|bridge br-int: deleted interface autoscal-19e274 on port 8
2021-08-01T13:06:20.476Z|00094|bridge|INFO|bridge br-int: deleted interface coredns--93cd05 on port 7
2021-08-01T13:06:20.476Z|00095|bridge|INFO|bridge br-int: deleted interface contour--0078ed on port 14
2021-08-01T13:06:20.476Z|00096|ofproto_dpif_rid|ERR|recirc_id 76 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00097|ofproto_dpif_rid|ERR|recirc_id 1 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00098|ofproto_dpif_rid|ERR|recirc_id 176 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00099|ofproto_dpif_rid|ERR|recirc_id 10 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00100|ofproto_dpif_rid|ERR|recirc_id 14 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00101|ofproto_dpif_rid|ERR|recirc_id 308 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00102|ofproto_dpif_rid|ERR|recirc_id 67 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00103|ofproto_dpif_rid|ERR|recirc_id 18 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00104|ofproto_dpif_rid|ERR|recirc_id 158 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00105|ofproto_dpif_rid|ERR|recirc_id 98 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00106|ofproto_dpif_rid|ERR|recirc_id 109 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00107|ofproto_dpif_rid|ERR|recirc_id 311 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00108|ofproto_dpif_rid|ERR|recirc_id 86 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00109|ofproto_dpif_rid|ERR|recirc_id 33 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00110|ofproto_dpif_rid|ERR|recirc_id 305 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.476Z|00111|ofproto_dpif_rid|ERR|recirc_id 105 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00112|ofproto_dpif_rid|ERR|recirc_id 34 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00113|ofproto_dpif_rid|ERR|recirc_id 309 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00114|ofproto_dpif_rid|ERR|recirc_id 55 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00115|ofproto_dpif_rid|ERR|recirc_id 80 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00116|ofproto_dpif_rid|ERR|recirc_id 29 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00117|ofproto_dpif_rid|ERR|recirc_id 35 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00118|ofproto_dpif_rid|ERR|recirc_id 304 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00119|ofproto_dpif_rid|ERR|recirc_id 307 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00120|ofproto_dpif_rid|ERR|recirc_id 310 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00121|ofproto_dpif_rid|ERR|recirc_id 5 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00122|ofproto_dpif_rid|ERR|recirc_id 197 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00123|ofproto_dpif_rid|ERR|recirc_id 131 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00124|ofproto_dpif_rid|ERR|recirc_id 68 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00125|ofproto_dpif_rid|ERR|recirc_id 47 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00126|ofproto_dpif_rid|ERR|recirc_id 94 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00127|ofproto_dpif_rid|ERR|recirc_id 41 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00128|ofproto_dpif_rid|ERR|recirc_id 85 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00129|ofproto_dpif_rid|ERR|recirc_id 24 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00130|ofproto_dpif_rid|ERR|recirc_id 83 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00131|ofproto_dpif_rid|ERR|recirc_id 185 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00132|ofproto_dpif_rid|ERR|recirc_id 45 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00133|ofproto_dpif_rid|ERR|recirc_id 63 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00134|ofproto_dpif_rid|ERR|recirc_id 72 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00135|ofproto_dpif_rid|ERR|recirc_id 102 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00136|ofproto_dpif_rid|ERR|recirc_id 84 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.477Z|00137|ofproto_dpif_rid|ERR|recirc_id 6 left allocated when ofproto (br-int) is destructed
2021-08-01T13:06:20.486Z|00002|daemon_unix(monitor)|INFO|pid 96 died, exit status 0, exiting

@lamw thanks for reporting it. I suspect it was because antrea-agent failed to start from some reason after rebooting, or kubelet failed to create antrea-agent pod. Could you check the status and log of antrea-agent pod on the rebooted node and upload if possible?

Antrea pods are indeed running:
k -n kube-system get pods
NAME                                                  READY   STATUS    RESTARTS   AGE
antrea-agent-tmxrr                                    2/2     Running   0          23h
antrea-controller-85c944dc84-8zzqt                    1/1     Running   0          23h
coredns-74ff55c5b-gvckz                               1/1     Running   0          23h
coredns-74ff55c5b-tsr62                               1/1     Running   0          23h
etcd-veba.primp-industries.local                      1/1     Running   0          23h
kube-apiserver-veba.primp-industries.local            1/1     Running   0          23h
kube-controller-manager-veba.primp-industries.local   1/1     Running   0          23h
kube-proxy-czdhb                                      1/1     Running   0          23h
kube-scheduler-veba.primp-industries.local            1/1     Running   0          23h

However, the networking is affected and hence I'm not able to get the logs as I always get this error for getting logs for any pods:
Error from server (NotFound): the server could not find the requested resource ( pods/log antrea-agent-tmxrr)

Here's the pod logs prior to reboot but I don't see any logs after the reboot
antrea-agent-before-reboot.log

I guess the status you got from k -n kube-system get pods was stale and didn't reflect the actual status of these Pods because:

There are no new antrea logs for both antrea-agent and antrea-controller so they were not running.
It was impossible that coredns pods were running well without antrea's network as they have tcp health probe enabled.
Normally the number of "RESTARTS" should be greater than 0 after the Node rebooted as kubelet would try to recreate all Pods.

Could you check the status of the Node via k get nodes? I suspect the Node is NotReady now. And you may find some clue from the kubelet log.

@tnqn I did see the NotReady status but assumed it was related to Antrea, since this was a recent change. Looking at the kubelet logs, it did give me a hint as it kept saying it can't find node veba which is the short hostname rather than the expected FQDN. It turns out something must have changed in latest PH3 and PH4 release where FQDN hostname goes back to short and hence causes this issue.
Manually updating the hostname and restart kubelet resolves it, so I need to ping Photon OS folks.


Continue adding support for user created node graphs

Closes #2043
Allows removing imports/exports
TODO: Renaming and reordering imports/exports

Deferred code review comments/requests from Hypercube in the precursor PR to this one:

https://github.com/GraphiteEditor/Graphite/pull/2097#discussion_r1835687634
https://github.com/GraphiteEditor/Graphite/pull/2097#discussion_r1835689486
https://github.com/GraphiteEditor/Graphite/pull/2097#discussion_r1835691147


List the PackageIdentifier of the package to be added to automation
Betterbird.Betterbird
Details about the application
https://www.betterbird.eu/
https://github.com/microsoft/winget-pkgs/tree/master/manifests/b/Betterbird/Betterbird

It is difficult to scrape things from the webpage. If @SpecterShell could find something from the application, it would be great. If there's any kind of automation from other package managers, it would also help.

https://www.betterbird.eu/start/versions.txt
This is the only source the program uses to check updates. The first two fields are used for matching editions and only the last field is used for comparing versions.
Besides, instead of auto downloading, users have to download the latest version from the website manually.
All the download links on https://www.betterbird.eu/downloads/ is redirectable. You can parse the version from the redirected link.


Setup trivy Github action

https://github.com/aquasecurity/trivy-action

configuring through security instead


Add the ability to change the base container image as a configuration option.

Active development of Centos 7 (the preferred distribution by BMD for Resolve) ended in 2020.   This repo currently uses Centos 8 Stream as the base container image. It would be cool to be able to lean on other RedHat derivatives like Centos 9 Stream, RockyOS and AlmaLinux.
I have manually tested most of these alternative base images however it would be good to have this as a runtime configuration parameter.

So essentially, all your base images belong to us?


[Impeller] Evaluate whether MTLTextureCompression needs to be configurable.

Context: https://github.com/flutter/engine/pull/40520
opting into lossy texture compression gives tremendous reported memory savings in newest iOS devices. We're not aware of any cases we can't use this. We'd like to make this the default, but filling this issue for tracking in case anything comes up.
From @chinmaygarde :
We already massage the image usage to make sure we opt into lossless compression. While lossless compression is great for bandwidth savings, there are usually (at least with Metal) no memory savings because Metal cannot guarantee any savings without compression and so must allocate an arena big enough for the entire uncompressed texture. In most cases, this is this bigger arena is wasted. We can observe this by comparing the results of lossy vs lossless compression to see cases where they are identical.
Compression doesn't necessarily mean a reduction in gamut so I wouldn't expect wide-gamut images to be uniquely affected by this but we should definitely eyeball the existing test.

I don't think this has come up after the latest stable release. Closing this since there is no action item. We can re-open if reports are filed of cases where this is visible regression.


Feature request: top level experiment id attribute for Ginkgo requests

In GitLab by @mweston on Jan 15, 2020, 12:00
Request to include a top level string attribute that maps to "experiment_id" in the structured request.
This would be used for Ginkgo, who is still using a manual process. After the request is accepted by Ginkgo at some point they will choose and prep an experiment id within their system.
The structured request should be given this id, so we can automatically line up expected to actual when Ginkgo uploads data.
This does not affect Strateos/Transcriptic. XPlan communicates with Strateos and informs our reactor of the Strateos experiment_id values that are chosen through an automated workflow.
What is the impact of not including this? Minor, but encourages a manual process:

Ginkgo tells someone with commit privileges on the cp-request repo of the experiment id (manual)
Experiment ID for the JSON structured request (generated by IP) is updated (manual)
Jenkins syncs the document to the catalog (automatic)

In GitLab by @mweston on Jan 15, 2020, 12:03
changed the description

In GitLab by @jakebeal on Apr 20, 2020, 09:20
assigned to @tramyn

In GitLab by @jakebeal on Apr 20, 2020, 09:20
Can this be handled by the parameter tables, or does it need some special case?

In GitLab by @mweston on Apr 20, 2020, 09:30
To clarify - no this is not a Strateos protocol parameter (which is what the parameter tables are for). This is a replacement of the experiment_id field value that the intent parser generates. It will change from the placeholder value that is currently generated, "experiment.tacc.tbd" to an actual experiment_id value.

In GitLab by @tramyn on Apr 26, 2020, 22:36
mentioned in merge request !106

In GitLab by @tramyn on Apr 26, 2020, 22:36
created merge request !106 to address this issue

In GitLab by @tramyn on May 6, 2020, 13:57
@mweston : A couple of questions here:

Who or where can I get programmatic access to obtain the experiment_id?
When does this experiment_id get generated?
You mention that Gingko has someone go into the cp-request repo to manually insert this value. Will it makes sense to have a user supply this information on a ER Doc, have this information stored in the sbol-dictionary spreadsheet, or have a backend entry point for intent parser to ping Gingko for this information.

In GitLab by @mweston on May 6, 2020, 14:08
@tramyn, good questions. I'll try and clarify:

The experiment_id will be filled in by a user in the ER. It is generated between when the request is completed, and when the experiment is actually run at Ginkgo.
We should support the ability to generate in the absence of an experiment_id value if one is not provided. You can use the existing placeholder, for example.
If one is provided, it should take the place of the placeholder "experiment.tacc.tbd"
The desired template is "experiment.lab.experiment_id_value". So, if an experiment_id of "foo123" is provided for a Ginkgo ER, the experiment_id generated by the IP should experiment.ginkgo.foo123
Strateos/Transcriptic requests do not need this, but I don't think it would hurt if it was provided. Strateos ER authors could provide an experiment_id that is semantically more meaningful.

There is no current way to access Ginkgo's system to retrieve this id (Ginkgo's system does not understand ERs/SRs), nor does it makes sense to store it in the dictionary (we are not translating between internal/external terms).
In the simplest sense, we are 1) Adding a field to the ER a user fills in and 2) Specifying where in the generated JSON that field applies.

In GitLab by @tramyn on May 12, 2020, 18:10
@mweston, I talked to Jake about this issue and the approach is to include a row under the lab table to include an experiment_id field. A prototype of this feature is shown here.
Following this approach, can a user generate a structured request if no experiment_id was provided? If the answer is yes, then experiment_id will be set to Unknown. Intent Parser will validate and record as a warning. If the answer is no, then Intent Parser will validate this as an error and stop a user from generating a structured request.

In GitLab by @mweston on May 12, 2020, 18:40
@tramyn Thanks, a couple things:
experiment_id is a required field, it currently generates for all requests as experiment.tacc.TBD:
This conforms to the schema requirement: https://gitlab.sd2e.org/sd2program/cp-request/blob/master/schemas/measurement-request-schema.json#L625 -> https://schema.catalog.sd2e.org/schemas/namespaced_identifier.json
Unknown breaks this and will fail validation. I suggested an alternative construction in the above comment https://gitlab.sd2e.org/sd2program/experimental-intent-parser/issues/167#note_17265
to summarize:

If experiment_id is present in the form, create an experiment_id value in the JSON as experiment.lab.value e.g. experiment.ginkgo.what_the_user_supplied_for_experiment_id in the Google Doc field.

If experiment_id is not present in the form, you can just use the existing behavior, e.g. pass in experiment.tacc.TBD. This won't break anything, and lets us know the field is a placeholder. Alternatively, this is not required, but it would be helpful to parse out the lab when constructing this placeholder value (I suspect the current value here is fixed/hardcoded to "experiment.tacc.TBD"), so an updated form would produce, for example, experiment.ginkgo.TBD which is more accurate given that we're parsing the user-supplied lab.

In both cases I would not fail validation or generate a warning / stop generation - both 1) and 2) above are acceptable/normal practices. Given the workflow I described above, it's common to create the ER and to start running the experiment at Ginkgo, only after which we actually have an valid ID to fill in, as it comes from Ginkgo's system. So we need the IP to initially parse, start running the experiment, then update once we have an id.

In GitLab by @tramyn on May 13, 2020, 17:06
closed via merge request !106

In GitLab by @tramyn on May 13, 2020, 17:06
mentioned in commit dca84fe13050bef65f9636c88731df21e131f297

In GitLab by @tramyn on May 13, 2020, 17:28
@mweston Sorry, I should've gone over previous comments before posting questions that have been answered. Intent Parser is updated to behave as you have described.
In short, intent parser generates experiment_id by using this format experiment.lab.value.
You can test out this new feature on http://intentparser2.sd2e.org.
To get it working, make sure to create a row in a lab table and structure it to the prototype described here.

In GitLab by @mweston on May 14, 2020, 08:23
Thanks @tramyn
This is producing an error on the example document: https://docs.google.com/document/d/1U3s3cOQabm-acFHIVccP8_VucMrKEOpRJUjBikXCQGU
("Tight-cycle DNASeq Learn Bacillus Experimental Request")
This is a schema validation error - see below. The lab in the experiment id needs to be lowercased here as part of the namespacing operation.
For testing, I modified 3 other documents, for a total of 4 you can use in addition to the one above.
https://docs.google.com/document/d/1XFC1onvvrhggNHiAci-iu2msXZQg3_SyiGdKnKUwrpM
https://docs.google.com/document/d/16eroq4UtIPhP89_PiKnvfi4wxV52vdKtUwPmBBu6OMc
https://docs.google.com/document/d/1ZPLjkEODVzRlqRA110cDVT3wK6nvvNr4wKMMPoDLnTY
{"errors": ["'experiment.Ginkgo.31188' does not match '^(name|experiment|sample|measurement|file|reference|product).(caltech|ginkgo|transcriptic|uw_biofab|marshall|emerald|tacc|pnnl_egbert|ucsb_yeung|duke_haase|psu_salis|geo).'

Failed validating 'pattern' in schema['properties']['experiment_id']:
    {'$comment': 'version: 2.2.0#master; generated: 20200421T232009+00:00; '
                 'source: '
                 'https://gitlab.sd2e.org/sd2program/python-datacatalog.git@5277784',
     '$id': 'https://schema.catalog.sd2e.org/schemas/namespaced_identifier.json',
     '$schema': 'http://json-schema.org/draft-07/schema#',
     'additionalProperties': False,
     'description': 'Namespaced identifier',
     'pattern': '^(name|experiment|sample|measurement|file|reference|product).(caltech|ginkgo|transcriptic|uw_biofab|marshall|emerald|tacc|pnnl_egbert|ucsb_yeung|duke_haase|psu_salis|geo).',
     'title': 'Namespaced Identifier',
     'type': 'string'}

On instance['experiment_id']:
    'experiment.Ginkgo.31188'"]}

https://schema.catalog.sd2e.org/schemas/namespaced_identifier.json

In GitLab by @mweston on May 14, 2020, 08:32
One additional request: the parsing here appears to be pretty sensitive:
Experiment_id: 29422 -> parses as experiment.Ginkgo.29422
Experiment_id:29422 -> Silently fails to parse (experiment.Ginkgo.TBD)
This is not intuitive, so I suggest we should either 1) accept the input "as-is" without the prefixed whitespace or 2) Provide a more intuitive error check or warning so the user can go in and correct the field to add the necessary whitespace.
Option 1) would be my suggestion.
While you're under the hood here, dropping the space in Lab: Ginkgo (so: Lab:Ginkgo) produces an HTTP 500/internal server error. Maybe this is following a similar parsing path?

In GitLab by @tramyn on May 18, 2020, 00:31
reopened

In GitLab by @tramyn on May 18, 2020, 12:40
mentioned in merge request !113

In GitLab by @tramyn on May 18, 2020, 12:40
closed via merge request !113

In GitLab by @tramyn on May 18, 2020, 12:40
mentioned in commit ea25ae6e1e7e7c626c4e5b0affaabc273542d60d

In GitLab by @tramyn on May 18, 2020, 19:28
@mweston There was a typo in the previous build. A new build is uploaded and you can test it on the same server. If you would like to try it out, it should be available for use.

In GitLab by @mweston on May 19, 2020, 17:12
@tramyn thanks. Was the typo related to the issues I was seeing? I am still seeing the same issues as in my previous note (link) - leading spaces are required for both the lab and the experiment id, which is pretty subtle.
The behavior I'm seeing is:

If the leading space missing in the experiment_id, the experiment_id silently fails to parse.
If the leading space missing in the lab, I get an HTTP 500/Internal Server Error

In GitLab by @tramyn on May 19, 2020, 17:27
@mweston Can you provide me a document that you are running this example on?
I just ran a unit test with an input an example that you have provided and intent parser will generate the expected value.
For example, this input Experiment_id:29422 will produce this output: experiment.tacc.29422.

In GitLab by @tramyn on May 19, 2020, 17:27
reopened

In GitLab by @tramyn on May 19, 2020, 17:56
I also tried this example on a live document and I'm not getting the same behavior.
This is a file that I removed white spaces from lab and experiment_id.

In GitLab by @mweston on May 19, 2020, 18:14
http://intentparser2.sd2e.org/document_request?1U3s3cOQabm-acFHIVccP8_VucMrKEOpRJUjBikXCQGU is that document - this is giving an HTTP 500 error. Perhaps I'm confused to which server you are running on/which I should be using (per the last message you sent, this was all on intentparser2). Have you pushed a release to production already?

In GitLab by @mweston on May 19, 2020, 18:17
http://intentparser.sd2e.org/document_request?1U3s3cOQabm-acFHIVccP8_VucMrKEOpRJUjBikXCQGU works.

In GitLab by @tramyn on May 19, 2020, 18:29
closed

In GitLab by @tramyn on May 28, 2020, 18:22
mentioned in merge request !117

In GitLab by @tramyn on May 28, 2020, 18:22
mentioned in commit 44b90feb257b1589ec1c939f8ad866ca37be9c34

In GitLab by @tramyn on Jun 12, 2020, 18:58
mentioned in commit 9704c3e6d93e671b9c0609d78d8dbf4ee9261d13

In GitLab by @tramyn on Jun 12, 2020, 18:58
mentioned in commit b6586cf162e6232a6785a6ecadf0966a3d7b9cb5

In GitLab by @tramyn on Jun 12, 2020, 18:58
mentioned in commit 5f94071f2ad8d919fc6637f7b4b07f831140dbb2


Added Reference to SliverWithKeepAliveWidget #69470

AdoptAWidget: SliverWithKeepAliveWidget
Added Reference in See Also Section
This pull request is:

[  ] A code sample
[x] More references
[  ] More explanation

closes #69470

Closing these ones out for now since the customer tests are still failing

Closing this for now until the customer_testing issue can be resolved


It's just Primer

no .css 😛
cc @jxnblk

Codecov Report

Merging #122 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff          @@
##           master   #122   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           5      5
  Lines         190    190
=====================================
  Hits          190    190

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 63a5b96...50dd479. Read the comment docs.


Add support for running test classes in Metals

https://scala-cli.virtuslab.org/docs/cookbooks/vscode

What does it mean to "run test classes in Metals"? I didn't understand the feature from the v0.0.8 release notes, nor the PR description, and no doc updates in the PR. Not being very familiar with the code base, even reading the PR diff isn't much help…

Hi @ches,
It means, that in VSCode you can run tests by pressing test/debug test button in test files. Here is described simple use cases.


[Question] "Reverse" tunnel scenario

Hello,
Many thanks for the project.
I am not a specialist on these topics and wondered if the present project could be adapted to a reverse-tunnel situation. By reverse tunnel I mean having a client initiating the connection to the server (let's say behind a residential NAT ISP) and having the possibility to tunnel back data from the server back to the client - as an example to reach to reach private subnets. I understand it is currently no possible, but would that be easily doable?
Many thanks,
Best

If a server is behind a NAT, you can have a node with a TCP proxy outside of the NAT boundaries and connect to it from the server machine (using again a TCP proxy). Then your clients may connect to that TCP proxy. So essentially you can establish a bridge from the server to a machine outside of the NAT boundaries.
This app supports the TCP proxy mode, btw. I hope this hepls.

Hello and thanks for your answer.
Indeed that would be a possibility, but that is essentially two tunnels, one from behind NAT to Outside NAT server, and then back-in via a second tcp-proxy as you mentioned.
What I had in mind taking the following terminology:

client: where http-tunnel is run
proxy-server: to where http-tunnel is building the tunnel and proxying the traffic
was more to use only one tunnel to do that, so instead of having http-tunnel only encapsulate and forward traffic back and forth from the client to the proxy-server (so client-initiated and returning traffic), also be able to haul-back data from the proxy-server back to the client (which may be behind a NAT) - even if that traffic was not necessarily initiated from the client. A bit like what ngrok and the likes are doing I guess. The idea here would be to benefit from an already existing stream without re-encapsulating the traffic back in another tunnel layer.

That may of course, not at all be a use-case for this project, but as you seemed very proficient with streams in rust I figured you may have some insight if it was achievable with it, or if it would be something entirely different.
Many thanks for taking the time.
Best

I see. This seems to be outside of the scope of this project. However, I can help you to review design/code if you decide to take on that task

Many thanks, I'll keep you in the loop if I end up taking it on.


Missing a codename property for a snippet element in a content type

Brief bug description
TS type for a snippet element in a content type is missing a codename property. However, according to the documentation, the API returns it.
Repro steps

Open the type and see the missing property

Expected behavior
The property is present
Test environment

Version 3.4.0

I wanted to clarify this issue. I can see that the view content type endpoint does return the codename of a snippet element, so the issue is just the missing property from ISnippetElementData in models/elements.content-type-element-models.ts?

You are correct. The property is missing in the type here. https://github.com/kontent-ai/management-sdk-js/blob/master/lib/models/elements/content-type-element.models.ts#L68-L72 I would even say that the property could be on the shared type (https://github.com/kontent-ai/management-sdk-js/blob/master/lib/models/elements/content-type-element.models.ts#L29-L32), because every element should have a codename.

@JiriLojda The documentation actually misses the codename element for content type snippet element ->

It likely depends on where this codename should be used or maybe the documentation is wrong.
@Nickm615 can you please investigate whether the codename is supported by API and whether the documentation is wrong or whether there is a distinction of models (e.g. when fetching or when updating..)

@Enngage You can't specify the codename when creating a new content type. It can only be generated by Kontent.ai. However, if you'd take a look at the response type of the POST endpoint or any other content type endpoint, you'd see the codename property.

It is always returned (I believe the documentation has it wrong that it is not marked as required in the response) and you can specify it when modifying a content type, but not when creating one.

I confirmed the behavior that element codename for a snippet can't be specified when creating a content type.  The response does contain the codename of the snippet element,

but it is always based on the name/codename of the snippet itself rather than the one specified in the request. As far as I can tell this matches the documentation. When you retrieve a content type using the MAPI, the snippet element always inherits the codename of the snippet its referencing. Additionally, when you query for the type using the REST API rather than the SDK the response is totally different

I also noticed that in the editor you can't see or edit the codename of a snippet element at all. From my perspective there is some ambiguity around the element, I'm not sure if the intention is for snippet elements to have codenames that can be set like every other element (if so, why aren't they in the editor?) or if the SDK response should instead look like the API response.
I'm hoping to get some clarity before I begin working on any changes to the SDK.

You can't edit the codename of a snippet element. That is correct. But the MAPI returns it for the element. The whole point of this issue is for the codename to be accessible when I receive (fetch) elements from MAPI. As you mentioned, the structure of the item variant is different in the raw API response and in the response provided by the SDK. That is fine, but the response provided by the SDK should give me the codename as well, which is not the case at the moment. (At least not according to the TypeScript definition.)
I don't think it matters how Kontent.ai generates the codename (i.e. that it is the codename of the snippet inside the element). It is some string identifying the element.


Add smtp support

This PR adds support for Dex to send emails via SMTP as an alternative to mailgun. Tested with the mailgun SMTP gateway, and verified the emails were going to mailgun using TLS or STARTTLS (depending on the port used) using wireshark.

almost there: a doc nit, and a question about conifg validation. Thanks Chance!

@bobbyrullo Updated in response to your comments, PTAL!

Thank Chancez!


rustic-cargo-comint-run was causing a Lisp error - wrong-type-argumen…

When attempting to run M-x rustic-cargo-comint-run for rust code reading from stdin I bumped into this issue. The wrong-type-argument error was captured in this piece of code in the rustic-cargo-run-get-relative-example-name() function, the often nil buffer-file-name was causing the error.
(if buffer-project-root
             (split-string (file-relative-name buffer-file-name buffer-project-root) "/") nil)))

The correct buffer file name is the name of the directory where the current source file sits (called here buffer-folder). I have obtained the name for this directory from (rustic-buffer-crate), in the following form:
(let* ((buffer-project-root (rustic-buffer-crate))
         (buffer-path-list (split-string buffer-project-root "\\/"))
	 (buffer-folder (nth (- (length buffer-path-list) 2) buffer-path-list))
...

the last line is simply fetching the last folder in the path retrieved by (rustic-buffer-crate).

@dcguim Do you think changing rustic-cargo-comint-run into this will instead fix it:
(defun rustic-cargo-comint-run (&optional arg)
  "Run 'cargo run' but for interactive programs.

If ARG is not nil, use value as argument and store it in `rustic-run-arguments'.
When calling this function from `rustic-popup-mode', always use the value of
`rustic-run-arguments'."
  (interactive "P")
  (let* ((run-args (rustic--get-run-arguments)))
    (pop-to-buffer-same-window
     (get-buffer-create rustic-run-comint-buffer-name))
    (unless (comint-check-proc (current-buffer))
    (rustic--cargo-repl-in-buffer
     (current-buffer)
     (concat "run" (cond
                    (arg
                     (setq rustic-run-comint-arguments
                           (read-from-minibuffer "Cargo run arguments: " rustic-run-comint-arguments)))
                    (run-args)
                    (t ""))))
    (rustic-cargo-run-comint-mode))))

Thanks, @psibi that works as well.

@dcguim Can you update your PR with that ?
Regarding the changes on rustic-cargo-run-get-relative-example-name, I'm not sure they are really required. But probably someone else can confirm that.

Will do. Yeah, I got more stable results when getting path information from (rustic-buffer-crate) perhaps we should be more careful with the setting of buffer-file-name:
"""Local in buffer rustic-cargo.el; global value is nil.
Automatically becomes permanently buffer-local when set.
This variable may be risky if used as a file-local variable.
Probably introduced at or before Emacs version 17."""

Thank you!


Public control-plane subnet is not accessible from internet

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version and Provider Version

Terraform v1.1.5
on linux_amd64

provider registry.terraform.io/hashicorp/cloudinit v2.2.0
provider registry.terraform.io/hashicorp/local v2.1.0
provider registry.terraform.io/hashicorp/null v3.1.0
provider registry.terraform.io/hashicorp/oci v4.63.0
provider registry.terraform.io/hashicorp/time v0.7.2

module "oke" {
source                                =   "oracle-terraform-modules/oke/oci"
version                               =   "4.0.0"
...
Affected Resource(s)

control plane subnet
Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file.
# Please remove any sensitive information from configuration files before sharing them.

Debug Output

Panic Output

Expected Behavior
The control plane subnet of a public OKE cluster should have port 6443 open.
This was the case with version 3.
Actual Behavior
The only sec list rule provisioned allow access from internal (private) addresses only
No | <IP_ADDRESS>/29 | TCP | All | 6443 |   | TCP traffic for ports: 6443
Steps to Reproduce

terraform apply

Important Factoids

References

Could you please use latest version and let us know still the issue persist.

Hello,
I am not cloning the repo.
Can you please tell me what should I set to use the latest?
module "oke" {
source = "oracle-terraform-modules/oke/oci"
version = "?.?.?"
...
Thanks a lot

@mailbox171 4.1.4 is the latest version.

@mailbox171 Thanks for reporting I have raised a issue for it . We will fix it asap.

@mailbox171: it looks like you using the module remotely. We've fixed and release a patch: v4.1.5. Please use this instead.

I've tested with v4.1.5 and setting the control_plane_type           = "public". It works fine

Testing ith v4.1.5 I still have the same issue.
Maybe I am doing something wrong.
I have a public endpoint created for the cluster. But the control-plane subnet only has one seclist allowing access from <IP_ADDRESS>/29.
Adding a seclist from <IP_ADDRESS>/0 to port 6443 solves the problem

Testing ith v4.1.5 I still have the same issue.
Maybe I am doing something wrong.
I have a public endpoint created for the cluster. But the control-plane subnet only has one seclist allowing access from <IP_ADDRESS>/29.
Adding a seclist from <IP_ADDRESS>/0 to port 6443 solves the problem

The same rule should exist in the control plane NSG. Can you verify that please?

I have only these 2 NSGs
Direction:
Ingress
Stateless:
No
Source Type:
CIDR
Source:
<IP_ADDRESS>/18
TCP
Source Port Range:
All
Destination Port Range:
6443
Allow:
TCP tra...
Allow worker nodes to control plane API endpoint communication
1BF721

Direction:
Ingress
Stateless:
No
Source Type:
CIDR
Source:
<IP_ADDRESS>/29
TCP
Source Port Range:
All
Destination Port Range:
6443
Allow:
TCP tra...
Allow operator host access to control plane. Required for kubectl/helm...
C22167

Can you please name the NSGs?

I see they have a description that identifies them clearly-
What do you mean by "names"?

The display names of the nsgs in the VCN

I have 4 NSGs
NSG: odadev-control-plane
Inside there are various rules, including the two rules I reported above
Other 3 NSGs: operator, workers, pub-lb

Like I said, if you set control_plane_type = "public", you should be able to access it.

I can only tell you what I see.
I set control_plane-type = public
run terraform
control plane provisioned in public subnet
endpoint with private and public IP (port 6443)
access from internet hangs
The only 2 Ingress rules I have to port 6443  mention "private" CIDRs sources (see above)
I add one neww rule to port 6443 with source <IP_ADDRESS>/0 in NSG control-plane
kubectl works

Setting "control_plane_allowed_cidrs" solved the problem.
Thank you


weird sprite naming bug?

I think this was fixed, but I'm leaving this note here just in case it isn't.

Uploading Screen Recording 2022-01-25 at 10.58.56 AM.mov…

https://user-images.githubusercontent.com/25539554/151012388-925d0595-2c70-46bd-a5ed-8effac1d2eeb.mov

Fixed by preventing re-render on name change.


Single - spa- angular

We are trying to use akita for single-spa design and try to store the data in localstorage using persistState() but its not working. We have created independent app and was able persist the state.
https://github.com/CanopyTax/single-spa-angular.
Do we have to set any property to force this for single-spa

Can you share the code, please?

You call persistState in the wrong file. You should call it in main.single-spa.ts. Please check your code before you open an issue, thanks.

Thank you so much! - It is working:)


I feel fooled by the plugin fisherman, it makes my life worser, many times.

I'm frustrated. I'm fresh, but the plugin crashed many times. Just now,  it crashed again, because i just key fisher update in my terminal.

@melotusme There was a dangerous upgrade recently, to 2.0, you can upgrade with:
curl -L git.io/fisher-up-me | fish

@melotusme There was a huge update recently, to 2.0, unfortunately changes are not backward compatible, but you can upgrade with:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh.

@melotusme There was a huge update recently, to 2.0, unfortunately changes are not backward compatible, but you can upgrade with:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh.

@melotusme There was a huge update recently, to 2.0, unfortunately changes are not backward compatible, but you can upgrade with:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh.

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh.
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh.
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh.
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above didn't work out for some reason, feel free to reopen this issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above doesn't work, please reopen the issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme There was a huge update recently, to 2.0, unfortunately, changes are not backward compatible, but you can upgrade with the following if you are stuck in 1.5:
curl -L git.io/fisher-up-me | fish

Let me know if the above fixed your issue and if you need more help, you can join.fisherman.sh. If the above doesn't work, please reopen the issue :)
Related: https://github.com/fisherman/fisherman/issues/223

@melotusme: Also, it would be very helpful to get actual information and screen output instead of a whining post about how you feel. This is the behavior of so called "lusers". We really want to help you. We need information for that. Please help us help you. Thanks.

@melotusme Also, please take no offence, but just in case there was a language miscommunication issue here, we have docs in Chinese too.
https://github.com/fisherman/fisherman/tree/master/docs/zh-CN

@bucaran that translation doesn't have the new upgrade instructions

Good point.
Ping @detailyang, if you have a second, can you fix it up? 🙏

I did not want to take offence at beginning. But I'm really frustrated. I can get rid of it by myself, but it takes my time !!! And it's not the first. I just type fisher update, and everything goes wront, I feel amazing!!!. BTW, I found it may conflict with mackup. Thanks for all your answers.

Run
curl -L git.io/fisher-up-me | fish

If that does not work:
function rm_fisherman
    if test -d ~/.config/fisherman
        rm -rf ~/.config/fisherman
    end

    if test -d ~/.cache/fisherman
        rm -rf ~/.cache/fisherman
    end
end

## Call rm_fisherman

rm_fisherman

Then, just use:
curl -Lo ~/.config/fish/functions/fisher.fish --create-dirs git.io/fisherman

to install fisherman 2.0 and you'll be in heaven.

I found this in the readme file, but current, the  latest version is 2.2 in fishshell.com.

fisherman was built for fish >= 2.3.0. If you are using 2.2.0, append the following code to your ~/.config/fish/config.fish for snippet support.

@melotusme Don't worry, be happy! :smile:
@bucaran IIRC, there is some bug with that curl ...|fish which doesn't remove the line that has been added in ~/.config/fish/config.fish. Not sure if I can reproduce it now but I had to manually removed that in the past.

@bucaran
Did you forget this???
if test -d ~/.local/share/fisherman
  rm -rf ~/.local/share/fisherman
end

@melotusme Nope, it is deleted.

@detailyang Maybe you can help with Chinese translation?

@melotusme All of you got fish 2.3???

I have 2.2.0.
The nuance is, fisherman was designed for 2.3.0, but it works just perfect in 2.2.0.

Did you forget this???

if test -d ~/.local/share/fisherman
rm -rf ~/.local/share/fisherman
end
Yes. Remove that too please.

fish shell has released 2.3b1 and now i'm ready to upgrade the readme.md for Chinese:)

@melotusme Please try fisherman again! I know the upgrade to 2.0 broke your shell, but 2.0 is so much better than 1.5 and after this there will never be more cross-versions breaking. My word.

already get fixed by removing fisherman totally， and reinstall everything.  :)@brj

@melotusme Awesome! Thanks.


environment object properties does not change.

Hi Team,
I am trying to run a code during the load testing is happening(eg push aggregated data to database).
I am using locust init event handler --> https://docs.locust.io/en/stable/api.html#locust.event.Events.init
Here is my code:

But the values is always None, It does not change to an integer when load-testing is finish, please help on this

process_exit_code is used for overriding the normal exit code. It is never actually set by Locust internally, only read.

Duplicate SO post: https://stackoverflow.com/questions/62694640/locust-hooks-run-a-custom-code-with-locust-performance-testing-environment


Run test_count_call_alleles on Cubed (alternative approach)

See #908
This takes an alternative approach to the one in #1249, by using map_blocks on both Dask and Cubed, rather than Xarray's apply_ufunc. This avoids the possible issue of the Dask graph changing (originally from #871) that was seen in #1249 by keeping the Dask code path the same.
I think this is the more pragmatic path forward as it allows us to experiment with Cubed by making minimal changes to Dask. (It also doesn't preclude using apply_ufunc in the future.)
Would love to get your thoughts @jeromekelleher and @timothymillar.

One issue that this work has highlighted is whether we allow chunking in core dimensions, ploidy in this case. With Dask we do allow ploidy to be chunked, but this only works because we rely on Dask's map_blocks to transparently concatenate chunks along chunked core dimensions. The Dask documentation at https://docs.dask.org/en/stable/generated/dask.array.map_blocks.html actually warns against relying on this, and says

Due to memory-size-constraints, it is often not advisable to use drop_axis on an axis that is chunked.

So I think we should explicitly disallow this case, and fail if the input dataset is chunked in the ploidy dimension. There is no reason to chunk in this dimension, and our VCF converters in sgkit and bio2zarr never do.
I bring it up in this PR since Cubed will never concatenate chunks in this way, which exposed the issue.

So I think we should explicitly disallow this case, and fail if the input dataset is chunked in the ploidy dimension. There is no reason to chunk in this dimension, and our VCF converters in sgkit and bio2zarr never do.

Agreed - there's no good reason to allow this. 2D chunks are more than enough complication here!

Added a check for chunking in the ploidy dimension.

Sorry for the radio silence - I was on leave. This approach looks good to me. There are a couple of cases where we use da.gufunc instead of da.map_blocks. But those should be trivial to replace with da.apply_gufunc if we want to match xarray/cubed.

Thanks @timothymillar! That sounds good to me. My plan is to get the aggregation functions needed for QC working under Cubed next - sample_stats, variant_stats, hardy_weinberg_test.


Futures implementation

Codecov Report

Merging #43 (95682c0) into main (940d682) will increase coverage by 0.71%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #43      +/-   ##
==========================================
+ Coverage   82.15%   82.86%   +0.71%
==========================================
  Files          12       13       +1
  Lines         381      391      +10
==========================================
+ Hits          313      324      +11
+ Misses         68       67       -1

Impacted Files
Coverage Δ

include/yaclib/ref.hpp
0.00% <ø> (ø)

include/yaclib/container/intrusive_ptr.hpp
100.00% <100.00%> (ø)

src/executor/inline.cpp
100.00% <0.00%> (ø)

src/executor/thread_pool.cpp
98.46% <0.00%> (+1.53%)
:arrow_up:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 940d682...95682c0. Read the comment docs.


Feature :: Refresh / Polling Graphql Schema inside Gateway mode

This PR closes #205

@mcollina
Let's make this feature awesome! :)

This needs tests.

I understand and I will do it asap

@mcollina
I have added tests for this feature
I needed to install https://github.com/sinonjs/fake-timers for working with timers (We don't need to use real timers for it)
Could you check the latest changes?
Thank you.

Hi, @mcollina
I wrote down an initial implementation of subscription test
That's weird, but subscription can't handle updates for a schema.
Gateway has an updated schema, user-service has an updated schema, even cache does not exist, but subscription can't find a new field.
Could you take a look at it? I hope, you will find my mistake
Thanks.

Wdyt @asciidisco

Let me throw my 2 cents in here; but first, please take my remakrs discouraging in any way. When I first saw the issue you opened & the PR I was super grateful, because this is something we'd also need for the software we're building on top of fastify-gql, so I'm super happy to see someone tacklingt that problemspace.
First question that popped up is, what happens in the error case, to be more precise, what happens when one of the requested services isn't able to answer in time when re-building the schema on the fly?
I think we can all agree on, that the network is not a 100% reliable source & there are many variables that could lead to a request not being answered in time. As far as I undertand the code, the whole federation will fail then, meaning, the gateway will bail out with an error. Please let me know if my assumption is wrong.
When starting the gateway, this might not be a bnig of a problem (and I would kinda expect the gateway to error out in such a scenario), as someone should be there to take care of this. When polling the downstream services, this problem could happen in the middle of the night, with nobody on call being able to take immediate action.
First impulse here might be, to just leave the failing node out of the gateway & just build the federated schema without it, as one of the next polls might be able to fix this problem by itself. Unfortuanately, this would work with schema stitching, but not with federation, as some services might extend other types & queries from others, depending on their availability.
For example, if you have a me query in a User service & maybe have a my Comments query in a Comments service, extending the me query from the User service, the federated schema won't be able to build if the User service is not available. So we might need to think of a concept dealign with this kind of errors during the schema build up.
F.e.: We flag some of our services in our service map with a { mandatory: true } option, telling our federation server which kind of services are necessary for a minimal working API. In the example above, User would be mandatory, while Comments wouldn't. This is also a thing you want, if not all of your federated services are under your control. F.e. when you start up an integration test environment for each of your pull requests (like we do), some of the services that are federation might take longer to boot up than the Gateway after the deplyoment & then we can start the Gateway & re-integrate them later, after the Gateway has booted, falgging them as  { mandatory: false }.
Having the service erroring out with a DOWNSTREAM exception on runtime, on the other hand, is some scenario that I think is perfectly fine. to me, this is even one of the benefits of federation, the API continous to work partially, even when one of the services is temprorarily unavailable. We treat this as an expected outcome of each operation in our software.
I'd also like to see the configuration being an object literal rather than a top level pollingInterval, the reason for this is that it is quite likely that this federated runtime schema change mechanic will be extended in the future.
Which is also the reason why it might be a good idea to export a function that allows for retriggering the schema fetch (basically exporting what is done withing the setInterval).
If, for some reason, users do not want to use periodic polling to re-fetch their schemas (f.e. we use a Kafka event to trigger that behaviour) they can either implement it on their own, or a 3rd party solution could be made available as a package.
Remarks in TL;DR form:

Error cases should be handled in case re-fetching goes wrong (or some way to handle this should be exposed in userland)
The configuration should be an object literal, so that it can be easier
The re-fetch should be available via a programmatic interface
Eventually, the serviceListcould take an additional flag, marking it as mandatory, but of course, that depends on the error resolution to be settled on

@asciidisco
Thank you for your detailed explanation of the problem.
I agree with your ideas and we can do it.

Error cases should be handled in case re-fetching goes wrong (or some way to handle this should be exposed in userland)

Error cases are an important part of each application. I agree that we need to handle it. We can do it by adding additional handler (that can be passed from properties) and a developer can configure it by himself.

Eventually, the serviceList could take an additional flag, marking it as mandatory, but of course, that depends on the error resolution to be settled on

We can extend the existing object of service parameters by adding gateway.services.mandatory parameter. It's quite good to have.

The re-fetch should be available via a programmatic interface

For now, we have ability to use it (https://github.com/mcollina/fastify-gql/pull/206/files#diff-168726dbe96b3ce427e7fedce31bb0bcR169). A developer is able to use server.graphql.gateway.refresh().

@iviaks Wow, that was quick 😄
If you want, I can do a review of the additions soon-ish.
At a first glance, it looks quite good, the only thing I've noticed that the documentation for that feature is missing, if you'd like, I could give you a hand with that one if needed.
@mcollina What should be done with the failing node 10.x tests? @iviaks changed the code to use Promise.allSettled as requested, but the 10.x tests are failing now of course.

Thank you, @asciidisco
I will try to write proper documentation for this feature :+1:

@mcollina What should be done with the failing node 10.x tests? @iviaks changed the code to use Promise.allSettled as requested, but the 10.x tests are failing now of course.

We need to keep supporting Node 10. https://www.npmjs.com/package/promise.allsettled can do the job.

@iviaks I'm  back from vacation & should have some spare time this week; so if there's anything I can assist you with, let me know. If it's possible for you somehow, I'd like to get this feature mergable this week.

@asciidisco
I hope we will merge this feature this week :)

I have added documentation for this feature and fixed merge conflicts with master

@asciidisco wdyt?

Thanks for your comments according to README @asciidisco
Also, Thanks a lot @mcollina for your help with this PR
Now it looks much better :)

@iviaks @asciidisco @mcollina
Hi,
I'm a little confused by the "mandatory" flag.
I'm trying to initialize gateway with 2 downstream services, both with mandatory: false flags, but I'm still getting an error (unhandled exception) when trying to start gateway if at least one service is running.
Have I misunderstood the purpose of the flag?
Running: "fastify-gql": "5.3.3"
app.register(GQL, {
  gateway: {
    services: [
      {
        name: 'api',
        url: process.env.GATEWAY_API_URL || 'http://localhost:4000/graphql',
        mandatory: false
      },
      {
        name: 'cms',
        url: process.env.GATEWAY_CMS_URL || 'http://localhost:1337/graphql',
        mandatory: false
      }
    ],
    pollingInterval: 30000
  }
})