Loading topology fails because its targeting the same pod for each node.

My original issue https://github.com/heketi/heketi/issues/822 and another issue same as mine https://github.com/gluster/gluster-kubernetes/issues/215.
The gist...
When using heketi-cli to load the topology file...
Creating cluster ... ID: 7590f296a56f6c782924eb657a3ca8cf
Creating node node01 ... ID: 7d048d4c409bd66605af14c23b97c6e1
Adding device /dev/vdb ... OK
Creating node node02 ... Unable to create node: Unable to execute command on glusterfs-jgfd3:
Creating node node03 ... Unable to create node: None of the nodes in cluster has glusterd running

The problem is when it goes to set up node02 it uses the same pod that node01 is using. So the command fails.. and then the pod starts rebooting over and over again. For some reason the host is now tainted and you can not run a gluster pod. As in NEVER, rebooting node, destorying and redeploying dameon set, nothing works.

heketi uses a single node to configure the entire GlusterFS cluster since it just needs to peer probe from the one node, and from there it can manage the whole cluster from the same node. Contacting the same pod for all operations is expected behaviour.
If you're willing to do some trouble shooting, I recommend the following:

Run gk-deploy --abort
On the target hosts wipe the drives, make sure they're not marked as LVM PVs ('pvs' on the target machines)
Delete the contents of '/var/lib/glusterd' and '/etc/glusterfs' on the target hosts
Manually deploy a new GlusterFS daemonset
kubectl exec a shell on one of the GlusterFS pods and verify that the IP addresses in your topology file can be pinged. If so, try to run 'gluster peer probe' with the IP addresses of the other nodes, one at a time.

@jarrpa ahhh... Now that makes sense =), I will run these commands in the next hour or so. Thanks for clearing up the architecture a bit. Hopefully I won't have to destroy and re-create node01 to get a pod to redeploy from it.

I'll admit, for my part I do my development in VMs, so when something goes wrong I have automation to destroy and redeploy the VMs. Apologies for my relatively novice troubleshooting experience. :)

@jarrpa Actually I didn't mention here in this issue but I did in the one I linked to, but what ever happens when the command fails, prevents me from sshing into the host.... so I have to destroy and rebuild node01.

I'm not sure what it does... but the node nodesn't like it..
ansible@rundeck:~$ kubectl get nodes
NAME       STATUS                     AGE       VERSION
master01   Ready,SchedulingDisabled   14h       v1.6.7+coreos.0
master02   Ready,SchedulingDisabled   14h       v1.6.7+coreos.0
master03   Ready,SchedulingDisabled   14h       v1.6.7+coreos.0
node01     NotReady                   14h       v1.6.7+coreos.0
node02     Ready                      14h       v1.6.7+coreos.0
node03     Ready                      14h       v1.6.7+coreos.0

Hmm... are you sure you're specifying bare storage devices that you've set aside exclusively for use by GlusterFS?

@jarrpa Yes I have dedicated dev's.
root@Node01:~# fdisk -l
Disk /dev/vda: 46.6 GiB,<PHONE_NUMBER>0 bytes, 97656250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/vdb: 46.6 GiB,<PHONE_NUMBER>0 bytes, 97656250 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

/dev/vda is OS and /dev/vdb is empty for glusterFS

Urgh... are you able to find any indication as to what's making the node not want to come back up? Anywhere in the boot or system logs?

@jarrpa I'm not able to access the node after gluster fails =), I just destroyed it and Im running through your steps you listed above with a fresh VM.
so far so good...
root@Master01:/deploy# kubectl label node node01 storagenode=glusterfs
node "node01" labeled
root@Master01:/deploy# kubectl label node node02 storagenode=glusterfs
node "node02" labeled
root@Master01:/deploy# kubectl label node node03 storagenode=glusterfs
node "node03" labeled
root@Master01:/deploy# kubectl create -f kube-templates/glusterfs-daemonset.yaml
daemonset "glusterfs" created
root@Master01:/deploy# kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
glusterfs-1d6h5   1/1       Running   0          1m
glusterfs-2hvkc   1/1       Running   0          1m
glusterfs-km84f   1/1       Running   0          1m

So I can ping and resolve hostnames from the gluster pods.
root@Master01:/deploy# kubectl exec -it glusterfs-km84f /bin/bash
[root@Node03 /]# ping node02
PING Node02 (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from Node02 (<IP_ADDRESS>): icmp_seq=1 ttl=59 time=0.784 ms
64 bytes from Node02 (<IP_ADDRESS>): icmp_seq=2 ttl=59 time=0.666 ms
64 bytes from Node02 (<IP_ADDRESS>): icmp_seq=3 ttl=59 time=0.722 ms
^C
--- Node02 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2051ms
rtt min/avg/max/mdev = 0.666/0.724/0.784/0.048 ms
[root@Node03 /]# gluster peer probe <IP_ADDRESS>
Connection failed. Please check if gluster daemon is operational.
[root@Node03 /]#

So peer probe is failing. How can I fix =), at least we are getting somewhere.

@jarrpa I noticed some guides say to open ports, does this need to be node on the phyisical vm's or is it taken care of on the gluster pods?
iptables -N HEKETI
iptables -A HEKETI -p tcp -m state --state NEW -m tcp --dport 24007 -j ACCEPT
iptables -A HEKETI -p tcp -m state --state NEW -m tcp --dport 24008 -j ACCEPT
iptables -A HEKETI -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT
iptables -A HEKETI -p tcp -m state --state NEW -m multiport --dports 49152:49251 -j ACCEPT

I noticed here https://github.com/gluster/gluster-kubernetes/issues/250#issuecomment-294309134 you mention opening up ports from the pre-req? I did not see such a step.

ugh the quickstart doesn't mention this... but the setup guide does mention the ports... https://github.com/gluster/gluster-kubernetes/blob/master/docs/setup-guide.md

Yes! Ports need to be opened prior to running this step.
I could see this as a bug in our documentation. :) The preamble of the gk-deploy tool mentions all the pre-reqs, but is it just too tempting to skip over it?

@jarrpa I ran the above iptable commands on all 3 hosts.
root@Master01:/deploy# kubectl create -f kube-templates/glusterfs-daemonset.yaml
daemonset "glusterfs" created
root@Master01:/deploy# kubectl exec -it glusterfs-8kp2d /bin/bash
[root@Node02 /]# ping node01
PING Node01 (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from Node01 (<IP_ADDRESS>): icmp_seq=1 ttl=59 time=1.10 ms
64 bytes from Node01 (<IP_ADDRESS>): icmp_seq=2 ttl=59 time=0.808 ms
^C
--- Node01 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.808/0.955/1.103/0.150 ms
[root@Node02 /]# ping node03
PING Node03 (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from Node03 (<IP_ADDRESS>): icmp_seq=1 ttl=59 time=1.75 ms
^C
--- Node03 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.750/1.750/1.750/0.000 ms
[root@Node02 /]# gluster peer probe <IP_ADDRESS>
Connection failed. Please check if gluster daemon is operational.
[root@Node02 /]# gluster peer probe <IP_ADDRESS>
Connection failed. Please check if gluster daemon is operational.

Hmm... something seems wrong with the networking. If all the pods are running then the gluster daemons are running. Do you need to do something to the firewall to apply the changes? See if restarting the glusterfs pods helps. Is there anything in /var/log/glusterfs that seems relevant?

from inside pod
[root@Node02 /]# cat /var/log/glusterfs/cli.log
[2017-08-06 16:03:25.387131] I [cli.c:759:main] 0-cli: Started running gluster with version 3.10.2
[2017-08-06 16:03:25.618488] I [MSGID: 101190] [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1
[2017-08-06 16:03:25.618923] I [socket.c:2404:socket_event_handler] 0-transport: disconnecting now
[2017-08-06 16:03:25.706224] W [socket.c:593:__socket_rwv] 0-glusterfs: readv on /var/run/glusterd.socket failed (No data available)
[2017-08-06 16:03:43.712085] I [cli.c:759:main] 0-cli: Started running gluster with version 3.10.2
[2017-08-06 16:03:43.964355] I [MSGID: 101190] [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1
[2017-08-06 16:08:17.400332] I [cli.c:759:main] 0-cli: Started running gluster with version 3.10.2
[2017-08-06 16:08:17.636277] I [MSGID: 101190] [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1
[2017-08-06 16:33:46.275360] I [cli.c:759:main] 0-cli: Started running gluster with version 3.10.2
[2017-08-06 16:33:46.512756] I [MSGID: 101190] [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1
[2017-08-06 16:33:46.513294] I [socket.c:2404:socket_event_handler] 0-transport: disconnecting now
[2017-08-06 16:33:46.616174] W [socket.c:593:__socket_rwv] 0-glusterfs: readv on /var/run/glusterd.socket failed (No data available)
[2017-08-06 16:36:00.297297] I [cli.c:759:main] 0-cli: Started running gluster with version 3.10.2
[2017-08-06 16:36:00.540765] I [MSGID: 101190] [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1

from glusterd.log
[2017-08-06 16:31:20.242044] I [MSGID: 106478] [glusterd.c:1449:init] 0-management: Maximum allowed open file descriptors set to 65536
[2017-08-06 16:31:20.242112] I [MSGID: 106479] [glusterd.c:1496:init] 0-management: Using /var/lib/glusterd as working directory
[2017-08-06 16:31:20.254403] E [rpc-transport.c:283:rpc_transport_load] 0-rpc-transport: /usr/lib64/glusterfs/3.10.2/rpc-transport/rdma.so: cannot open shared object file: No such file or directory
[2017-08-06 16:31:20.254459] W [rpc-transport.c:287:rpc_transport_load] 0-rpc-transport: volume 'rdma.management': transport-type 'rdma' is not valid or not found on this machine
[2017-08-06 16:31:20.254481] W [rpcsvc.c:1661:rpcsvc_create_listener] 0-rpc-service: cannot create listener, initing the transport failed
[2017-08-06 16:31:20.254506] E [MSGID: 106243] [glusterd.c:1720:init] 0-management: creation of 1 listeners failed, continuing with succeeded transport
[2017-08-06 16:31:26.911514] E [MSGID: 101032] [store.c:433:gf_store_handle_retrieve] 0-: Path corresponding to /var/lib/glusterd/glusterd.info. [No such file or directory]
[2017-08-06 16:31:26.911629] E [MSGID: 101032] [store.c:433:gf_store_handle_retrieve] 0-: Path corresponding to /var/lib/glusterd/glusterd.info. [No such file or directory]
[2017-08-06 16:31:26.911633] I [MSGID: 106514] [glusterd-store.c:2219:glusterd_restore_op_version] 0-management: Detected new install. Setting op-version to maximum : 31000
[2017-08-06 16:31:26.954085] I [MSGID: 106194] [glusterd-store.c:3776:glusterd_store_retrieve_missed_snaps_list] 0-management: No missed snaps list.
Final graph:
+------------------------------------------------------------------------------+
  1: volume management
  2:     type mgmt/glusterd
  3:     option rpc-auth.auth-glusterfs on
  4:     option rpc-auth.auth-unix on
  5:     option rpc-auth.auth-null on
  6:     option rpc-auth-allow-insecure on
  7:     option transport.socket.listen-backlog 128
  8:     option event-threads 1
  9:     option ping-timeout 0
 10:     option transport.socket.read-fail-log off
 11:     option transport.socket.keepalive-interval 2
 12:     option transport.socket.keepalive-time 10
 13:     option transport-type rdma
 14:     option working-directory /var/lib/glusterd
 15: end-volume
 16:
+------------------------------------------------------------------------------+
[2017-08-06 16:31:26.961940] I [MSGID: 101190] [event-epoll.c:629:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1
[2017-08-06 16:33:46.513695] I [MSGID: 106487] [glusterd-handler.c:1242:__glusterd_handle_cli_probe] 0-glusterd: Received CLI probe req <IP_ADDRESS> 24007
[2017-08-06 16:33:46.514800] I [MSGID: 106129] [glusterd-handler.c:3690:glusterd_probe_begin] 0-glusterd: Unable to find peerinfo for host: <IP_ADDRESS> (24007)
[2017-08-06 16:33:46.578797] W [MSGID: 106062] [glusterd-handler.c:3466:glusterd_transport_inet_options_build] 0-glusterd: Failed to get tcp-user-timeout
[2017-08-06 16:33:46.578878] I [rpc-clnt.c:1059:rpc_clnt_connection_init] 0-management: setting frame-timeout to 600
pending frames:

also noticed 2 gluster folders...
[root@Node02 /]# cat /var/log/glusterfs
glusterfs/     glusterfs_bkp/

is there a curl or telnet I could do to verify connectivity issue?

@jarrpa for some reason the pods are started and healthy.... but gluster has failed...
root@Master01:/deploy# kubectl exec -it glusterfs-pw5pm -- /bin/bash
[root@Node02 /]# systemctl status glusterd.service -l
● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
   Active: failed (Result: signal) since Sun 2017-08-06 16:57:09 UTC; 2min 45s ago
  Process: 50 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 51 (code=killed, signal=SEGV)

Aug 06 16:57:09 Node02 glusterd[51]: time of crash:
Aug 06 16:57:09 Node02 glusterd[51]: 2017-08-06 16:57:09
Aug 06 16:57:09 Node02 glusterd[51]: configuration details:
Aug 06 16:57:09 Node02 glusterd[51]: argp 1
Aug 06 16:57:09 Node02 glusterd[51]: backtrace 1
Aug 06 16:57:09 Node02 glusterd[51]: dlfcn 1
Aug 06 16:57:09 Node02 glusterd[51]: libpthread 1
Aug 06 16:57:09 Node02 systemd[1]: glusterd.service: main process exited, code=killed, status=11/SEGV
Aug 06 16:57:09 Node02 systemd[1]: Unit glusterd.service entered failed state.
Aug 06 16:57:09 Node02 systemd[1]: glusterd.service failed.
[root@Node02 /]#

Okay.. I think i got it narrowed down... destroying everything and doing a last check... for some reason running gluster peer probe xxx.xxx.xxx.xxx is causing the gluster service to fail.

@jarrpa
root@Master01:~# kubectl get pods
NAME              READY     STATUS    RESTARTS   AGE
glusterfs-dpkpm   1/1       Running   0          3m
glusterfs-rccmv   1/1       Running   0          3m
glusterfs-ws0v1   1/1       Running   0          3m
root@Master01:~# kubectl exec -it glusterfs-rccmv -- /bin/bash
[root@Node03 /]# systemctl status glusterd.service -l
● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor pre                                                                                set: disabled)
   Active: active (running) since Sun 2017-08-06 17:13:12 UTC; 4min 3s ago
  Process: 50 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level                                                                                $LOG_LEVEL $GLUSTERD_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 51 (glusterd)
   CGroup: /docker/5d5b838d8461ba7e93d5ec7e42d85f073f96128d6a87092148fcc87724fb5                                                                                128/system.slice/glusterd.service
           └─51 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO

Aug 06 17:13:06 Node03 systemd[1]: Starting GlusterFS, a clustered file-system s                                                                                erver...
Aug 06 17:13:12 Node03 systemd[1]: Started GlusterFS, a clustered file-system se                                                                                rver.
[root@Node03 /]# ping node02
PING Node02 (<IP_ADDRESS>) 56(84) bytes of data.
64 bytes from Node02 (<IP_ADDRESS>): icmp_seq=1 ttl=59 time=0.931 ms
64 bytes from Node02 (<IP_ADDRESS>): icmp_seq=2 ttl=59 time=1.10 ms
^C
--- Node02 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.931/1.015/1.100/0.090 ms
[root@Node03 /]# gluster peer probe <IP_ADDRESS>
Connection failed. Please check if gluster daemon is operational.
[root@Node03 /]# systemctl status glusterd.service -l
● glusterd.service - GlusterFS, a clustered file-system server
   Loaded: loaded (/usr/lib/systemd/system/glusterd.service; enabled; vendor preset: disabled)
   Active: failed (Result: signal) since Sun 2017-08-06 17:17:52 UTC; 3s ago
  Process: 50 ExecStart=/usr/sbin/glusterd -p /var/run/glusterd.pid --log-level $LOG_LEVEL $GLUSTER                                                                                D_OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 51 (code=killed, signal=SEGV)

Aug 06 17:13:06 Node03 systemd[1]: Starting GlusterFS, a clustered file-system server...
Aug 06 17:13:12 Node03 systemd[1]: Started GlusterFS, a clustered file-system server.
Aug 06 17:17:52 Node03 glusterd[51]: pending frames:
Aug 06 17:17:52 Node03 systemd[1]: glusterd.service: main process exited, code=killed, status=11/SE                                                                                GV
Aug 06 17:17:52 Node03 systemd[1]: Unit glusterd.service entered failed state.
Aug 06 17:17:52 Node03 systemd[1]: glusterd.service failed.

I've been staring at this on and off for a while, and I'm stumped. I'll try to get some more eyes to have a look at this early this week.

Thanks, It's possible I still need to change the iptable rules. I added them to the input chain, but they are behind the calico-INPUT chain, I don't think that matters... but after all the work I put into it the last few days I have lost my will to continue lol. Give me a day or 2 and I will stand up a fresh cluster with the accept rules in several spots or I will kill off all the rules and start with empty iptables and try again.

@shadycuz do you have passwordless ssh setup?

Into the Nodes? Yes but not from master. The instructions say some where that the deploy folder should be copied to master, my ansible machine has passwordless SSH access to all the machines, should I run it from that machine or should I copy my key to master so it can ssh into the nodes @erinboyd ?

It seems the thing that's failing is that glusterd is crashing as soon as he tries to do a peer probe. That does not require use of any SSH keys, but it does explain why heketi can add the first node, add the first device, and then fails on everything else.
@shadycuz I haven't been able to grab anyone else to look at this yet, so I'll try again. Can you repeat the steps you did to crash the glusterd process on the first GlusterFS pod, and then:

Get the cli and glusterd logs on that node
Verify the state of the glusterd process on the node you tried to peer probe, and see if glusterd.log shows any sign of having received the probe

@jarrpa Yes I'm still interested in working through this but it may be some time. This weekend or next. I will need to stand up a new cluster again, and I want to try putting those rules on another chain that may make a difference, but if I'm still crashing the pod I will post the logs from both nodes.

@shadycuz No prob, I'll try to keep an eye out for more notifications here. :) And thanks for updating the title!

I have the same problem. Do you fixed @shadycuz ???

@felixPG I have not but I was going to try a different networking plugin than calico next.

@shadycuz  I have a doubt whether stale configuration present causing glusterd issue.
Ensure you cleanup following directories on the nodes before setting up the pods.
So, rm -rf /var/lib/heketi  /etc/glusterfs  /var/lib/glusterd  /var/log/glusterfs and try setting up again.
Also, I remember seeing issue during gluster deployment, if  rpcbind.socket service is running in host.
Could you check the status  and try disabling it ?

I has similar issue with a 1.7.5 kubernetes cluster deployed on CentOS 7. I have firewalld stopped & disabled.
repo tag: v1.2.0
I tested a freshly installed glusterfs-daemonset manually (entering the pods of the daemonset), found the following:

glusterd crashed immediately when command "gluster peer probe" was issued.
glusterd couldn't be restarted as long as /var/lib/glusterd/peers wasn't empty
after removing all files under /var/lib/glusterd/peers glusterd could be restarted.
TCP/UDP port 24008 weren't listened by any process even if glusterd was running

A few months ago, I ran into a similar issue with a manually deployed glusterfs cluster, and I fixed the issue by manually editing files under /var/lib/glusterd/peers.

@torshie What networking solution are you using?

@jarrpa Tried both flannel & canal, same.  The generated files under /var/lib/glusterd/peers are like this:

[root@smart1 peers]# cat <IP_ADDRESS>
uuid=00000000-0000-0000-0000-000000000000
state=0
hostname1=<IP_ADDRESS>

Finally found a solution to this problem solved, it's a bug in glusterd. The default reserved local port range ( net.ipv4.ip_local_reserved_ports=30000-32767 ) set by kubespray would cause glusterd to crash. So a simple workaround would be lower the upper bound, e.g. net.ipv4.ip_local_reserved_ports=30000-32000
Check this link https://www.spinics.net/lists/gluster-users/msg31812.html

@torshie Thank you so much for your research into this problem. I have not had the time to continue working on this. I will stand up a new cluster with kubespray and lower the upper bound and report back.

No need to create a new kube cluster just change kernel parameters with
sysctl or /proc filesystem manipulation on the host, then recreate the
gluster cluster
On Sep 13, 2017 23:22, "Levi Blaney"<EMAIL_ADDRESS>wrote:
@torshie https://github.com/torshie Thank you so much for your research
into this problem. I have not had the time to continue working on this. I
will stand up a new cluster with kubespray and lower the upper bound and
report back.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/gluster/gluster-kubernetes/issues/286#issuecomment-329202821,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABKIAfnq4YrVXzpWwmCMC7IGHSMwwS_zks5sh_MlgaJpZM4Ouu-C
.

@torshie but I destroyed my last cluster and never got around to building a new one ;)

@jarrpa back at it again all this time later =)
Using Kubernetes CLI.                                                                                [0/1585]│from <IP_ADDRESS>
Using namespace "default".                                                                                │shadycuz@rundeck:~$ sudo su ansible
Checking for pre-existing resources...                                                                               │[sudo] password for shadycuz:
  GlusterFS pods ... not found.                                                                                │ansible@rundeck:/home/shadycuz$ cd ~
  deploy-heketi pod ... not found.                                                                                │ansible@rundeck:~$ cat repos/scaleway
  heketi pod ... not found.                                                                                │-kubernetes-infra/inventory
  gluster-s3 pod ... not found.                                                                                │master01 ansible_ssh_host=<IP_ADDRESS>
Creating initial resources ... serviceaccount "heketi-service-account" created                                       │ ip=<IP_ADDRESS>
clusterrolebinding "heketi-sa-view" created                                                                          │master02 ansible_ssh_host=<IP_ADDRESS>
clusterrolebinding "heketi-sa-view" labeled                                                                          │ ip=<IP_ADDRESS>
OK                                                                                │master03 ansible_ssh_host=<IP_ADDRESS>
node "compute01" labeled                                                                                │5 ip=<IP_ADDRESS>
node "compute02" labeled                                                                                │compute01 ansible_ssh_host=<IP_ADDRESS>
node "compute03" labeled                                                                                │ ip=<IP_ADDRESS>
daemonset "glusterfs" created                                                                                │compute02 ansible_ssh_host=<IP_ADDRESS>
Waiting for GlusterFS pods to start ... OK                                                                           │9 ip=<IP_ADDRESS>
secret "heketi-config-secret" created                                                                                │compute03 ansible_ssh_host=<IP_ADDRESS>
secret "heketi-config-secret" labeled                                                                                │ ip=<IP_ADDRESS>
service "deploy-heketi" created                                                                                │
deployment "deploy-heketi" created                                                                                │[kube-master]
Waiting for deploy-heketi pod to start ... OK                                                                        │master01
Creating cluster ... ID: 669d68bc6ebaa53652c3414c124c78f0                                                            │master02
Allowing file volumes on cluster.                                                                                │master03
Allowing block volumes on cluster.                                                                                │
Creating node compute01 ... ID: 02343b26f7d7ff70450cd7fb82da0488                                                     │[etcd]
Adding device /dev/vdb ... OK                                                                                │master01
Creating node compute02 ... ID: 34d4f4735fa29ad6988c7b0e28561fed                                                     │master02
Adding device /dev/vdb ... OK                                                                                │master03
Creating node compute03 ... ID: fbc1ec005cec8b2a6b4a2261460a0407                                                     │
Adding device /dev/vdb ... OK                                                                                │[kube-node]
heketi topology loaded.                                                                                │compute01
Error: Unable to execute command on glusterfs-7kgwl:   /usr/sbin/modprobe failed: 1                                  │compute02
thin: Required device-mapper target(s) not detected in your kernel.                                                  │compute03
Run `lvcreate --help' for more information.                                                                          │
command terminated with exit code 255                                                                                │[k8s-cluster:children]
Failed on setup openshift heketi storage                                                                             │kube-node
This may indicate that the storage must be wiped and the GlusterFS nodes must be reset.

I guess those modules werent installed on my nodes?

@jarrpa seemed to run okay a second time.
whats the admin key?
Using Kubernetes CLI.                                                                                │logout
Using namespace "default".                                                                                │Connection to compute02 closed.
Checking for pre-existing resources...                                                                           │ansible@rundeck:~$ ssh root@compute03
  GlusterFS pods ... found.                                                                                │               _
  deploy-heketi pod ... found.                                                                                │ ___  ___ __ _| | _____      ____ _ _   _
  heketi pod ... not found.                                                                                │/ __|/ __/ _` | |/ _ \ \ /\ / / _` | | | |
  gluster-s3 pod ... not found.                                                                                │\__ \ (_| (_| | |  __/\ V  V / (_| | |_| |
Creating initial resources ... Error from server (AlreadyExists): error when creating "/root/gluster-kubernetes/$│|___/\___\__,_|_|\___| \_/\_/ \__,_|\__, |
eploy/kube-templates/heketi-service-account.yaml": serviceaccounts "heketi-service-account" already exists       │                                    |___/
Error from server (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "heketi-sa-view" already exists │
clusterrolebinding "heketi-sa-view" not labeled                                                                  │Welcome on Ubuntu Xenial (16.04 LTS) (GNU/Linux 4.4.94-mainline-rev1 x86_64 )
OK                                                                                │
Found node compute01 on cluster 669d68bc6ebaa53652c3414c124c78f0                                                 │System information as of: Fri Oct 27 21:06:27 UTC 2017
Found device /dev/vdb                                                                                │
Found node compute02 on cluster 669d68bc6ebaa53652c3414c124c78f0                                                 │System load:    2.55            Int IP Address: <IP_ADDRESS>
Found device /dev/vdb                                                                                │Memory usage:   0.0%            Pub IP Address:
Found node compute03 on cluster 669d68bc6ebaa53652c3414c124c78f0                                                 │Usage on /:     8%              Swap usage:     0.0%
Found device /dev/vdb                                                                                │Local Users:    0               Processes:      149
heketi topology loaded.                                                                                │Image build:    2017-01-05      System uptime:  8:19 hours
Saving /tmp/heketi-storage.json                                                                                │Disk nbd0:      l_ssd 50G
secret "heketi-storage-secret" created                                                                           │Disk nbd1:      l_ssd 50G
endpoints "heketi-storage-endpoints" created                                                                     │
service "heketi-storage-endpoints" created                                                                       │Documentation:  https://scaleway.com/docs
job "heketi-storage-copy-job" created                                                                            │Community:      https://community.scaleway.com
service "heketi-storage-endpoints" labeled                                                                       │Image source:   https://github.com/scaleway/image-ubuntu
deployment "deploy-heketi" deleted                                                                               │
job "heketi-storage-copy-job" deleted                                                                            │Last login: Fri Oct 27 20:45:09 2017 from <IP_ADDRESS>
pod "deploy-heketi-5c45f969bd-wtxwm" deleted                                                                     │root@compute03:~# modprobe fuse
service "deploy-heketi" deleted                                                                                │root@compute03:~# modprobe dm_mirror
secret "heketi-storage-secret" deleted                                                                           │root@compute03:~# modprobe dm_snapshot
service "heketi" created                                                                                │root@compute03:~# modprobe dm_thin_pool
deployment "heketi" created                                                                                │root@compute03:~#
Waiting for heketi pod to start ... OK                                                                           │root@compute03:~#
                                                                                │root@compute03:~# ls
heketi is now running and accessible via http://<IP_ADDRESS>:8080 . To run                                      │root@compute03:~# exit
administrative commands you can install 'heketi-cli' and use it as follows:                                      │logout
                                                                                │Connection to compute03 closed.
  # heketi-cli -s http://<IP_ADDRESS>:8080 --user admin --secret '<ADMIN_KEY>' cluster list

Seem like no auth =) so everything seems to be working, going to try a dynamic provisioner out soon!

Thanks @jarrpa and @torshie


mec15xxevb_assy6853:running samples/drivers/kscan/ failed

Describe the bug
running samples/drivers/kscan, and the result just keep looping until the system hangs.
To Reproduce
Steps to reproduce the behavior:
west build -b mec15xxevb_assy6853 samples/drivers/kscan
~/software/ci/tools/usbgpio_ftdi/pre_script.sh
west flash
~/software/ci/tools/usbgpio_ftdi/post_script.sh
see error
*** Booting Zephyr OS build v2.4.0-rc1-11-g8c3efc7be5fe  ***
Kscan matrix sample application
[00:00:01.008,148]  main.block_matrix_callback: block host : 0
[00:00:04.008,148]  main.block_matrix_callback: block host : 1
[00:00:07.008,148]  main.block_matrix_callback: block host : 0
[00:00:10.008,148]  main.block_matrix_callback: block host : 1
[00:00:13.008,148]  main.block_matrix_callback: block host : 0
[00:00:16.008,148]  main.block_matrix_callback: block host : 1
[00:00:19.008,148]  main.block_matrix_callback: block host : 0
[00:00:22.008,148]  main.block_matrix_callback: block host : 1
[00:00:25.008,148]  main.block_matrix_callback: block host : 0
[00:00:28.008,148]  main.block_matrix_callback: block host : 1
[00:00:31.008,148]  main.block_matrix_callback: block host : 0
[00:00:34.008,148]  main.block_matrix_callback: block host : 1
[00:00:37.008,148]  main.block_matrix_callback: block host : 0
[00:00:40.008,148]  main.block_matrix_callback: block host : 1
[00:00:43.008,148]  main.bloc
.
.
.
Environment (please complete the following information):
OS: Fedora28
Toolchain: Zephyr-sdk-0.11.3
Commit ID: g8c3efc7be5fe

To run that sample necessary to connect a keyboard https://www.fujitsu.com/us/pdut/detail/1183530/input/FKB7401-001
It is strange that sample even launched without a connected keyboard.


A method can only be hooked once per class hierarchy

A method can only be hooked once per class hierarchy!
But If I want to hook UIViewController and UINavigationController 's viewDidLoad method for different purpose.
What should I do?

That doesn't work for now - nothing you can do here.

May i ask why there's such limitation please? Thank you very much in advance.


Tail loading data with dynamic cell size issue

Hi, so what I'm trying to do is to combine the "tail loading" example with "self sizing cell" one to achieve a social feed page-like. I have updated the SelfSizingCellController.swift to include the dragging delegate of scroll view to let it able to calculate the distance and fake a load more with duplicated data (please look at the screenshot), but every time after finished loading and update the new data, the content offset of collection view was reset to some random point and somehow the scroll up or down become crazy. Thanks for any help guys!

Hmm, this is honestly probably a limitation with self-sizing cells and UICollectionView. If you can provide a sample project we can poke around and try to find a solution, but I remember UITableView auto height cells having weird content offset issues too.

Examples-iOS.zip
Sure, this is the sample project which I combined tail-loading and self-sizing. Previously I make this work by using UITableView along with autolayout constraints applied on cells and return the UITableViewAutomaticDimension for the cell height delegate, also added a cache of height t o resolve some jumpy scrolling: http://stackoverflow.com/questions/27996438/jerky-scrolling-after-updating-uitableviewcell-in-place-with-uitableviewautomati
I wonder how it works in Instagram with dynamic cell height and tail loading also.

Bump bump bump, running into this issue as well!

@jamesrisberg we've got other estimated size issues floating around (#452). It looks like there are some weird behaviors going on. Estimated size is dependent on UICollectionViewFlowLayout and I'm trying to avoid any layout-specific fixes. However if we can't find a common solution we might have to.

@rnystrom Yeah, the content offsets get real wonky and sections start overlapping each other. I've just moved to calculating the heights manually for now, which isn't the end of the world since I'm just sizing cells for single textViews and the calculation is pretty lightweight.
Definitely something to be fixed. Maybe abstracting the layout to take any layout (Flow or otherwise) and making a UICollectionViewFlowLayout behind the scenes, since everything you can accomplish with a standard layout object you should be able to accomplish with a flow layout, but not vice versa.
Gonna do a little digging when I have the time and see if that's a viable path to go down

Closing to track at #516


Add dependencies of xtensor

We noticed that xtensor was added to the installed libraries 🎉 , but it is missing the xtl dependency.
There is also another header-only optional dependency, called xsimd, which is a high-level wrapper to SIMD compiler intrinsics.
cc @RabsRincon

Hi, sorry I took so long to get back to you! Thanks for noticing this issue and for providing the fix, we're extremelly grateful. I've also updated the "docs" so I don't forget to check for dependencies ever again.
Let us know if we can do any other improvements to better support xtensor in CE.
:)


Missing component name of Modelica.Electrical.MultiPhase.Basic.MultiStarResistance

Reported by beutlich on 6 Oct 2015 10:12 UTC
Modelica.Electrical.MultiPhase.Basic.MultiStarResistance is the only element in Modelica.Electrical.MultiPhase.Basic without the component name displayed. Is this by design? See also #1416 and #1655.

Migrated-From: https://trac.modelica.org/Modelica/ticket/1794

Comment by christiankral on 2 Nov 2015 06:50 UTC
Added component name and resistance value to Modelica.Electrical.MultiPhase.Basic.MultiStarResistance in f265a5299a46918c00a57f106ed0d2cb7822e748.

Changelog modified by christiankral on 2 Nov 2015 06:50 UTC
Added component name and resitance value to Modelica.Electrical.MultiPhase.Basic.MultiStarResistance

Modified by christiankral on 2 Nov 2015 06:51 UTC

Comment by beutlich on 2 Nov 2015 09:07 UTC
No need for Release Notes on development tickets (since MultiStarResistance never was released).

Changelog removed by beutlich on 2 Nov 2015 09:07 UTC

Comment by jmattsson on 2 Nov 2015 12:07 UTC
882d1a9584527c514b1964a86b1f22fa18f52212
Fixed additional syntax error introduced by f265a5299a46918c00a57f106ed0d2cb7822e748.


Compilation Error with navbar.component.sass

The code cannot be compiled due to a minute error in the code indentation in navbar.component.sass
please fix it ASAP.

This didnt fix the issue, it got rid of the background color.

The issue is resolved with the latest commit 585ccaa


DBeaver lacks query execution plan for SQL server

The version information of DBeaver, which I use, is as follows:

Currently, it is not possible to see the execution plan for SQL queries for SQL server database. Is there any reason for not having this feature? Only for this feature, it is required to use SQL Server Management Studio. So it will be nice to have this feature in DBeaver.

It is available in EE version only


gql: 0.5.0 -> 0.6.0

Diff: https://github.com/AmrDeveloper/GQL/compare/0.5.0...0.6.0
Changelog: https://github.com/AmrDeveloper/GQL/releases/tag/0.6.0
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 253686 run on aarch64-darwin 1

1 package built:

gql


Please add new device to plugin

Could you please add this device?
[Light] is not supported, do create a GitHub issue with the following info:
[33] {"bindInfos":{"alice":["276850ac-4115-4952-a13c-3eb8ce92f0d9_eWeLinkAliceSmartHome"],"miot":["276850ac-4115-4952-a13c-3eb8ce92f0d9_ewelink-miot-v1"]},"version":7,"switch":"off","bright":100,"colorR":215,"colorG":226,"colorB":255,"mode":1,"light_type":2,"fwVersion":"3.0.0","rssi":-63}.

Will have a look. could you find a web link to this device so I know what it is?
And a screenshot of how it looks in the ewelink app?
Thanks!

It is light Mangotek model: RLD60C0E27

and the device control page screenshot?

Sure

Could you use the ewelink app to set a colour temperature (the blue to orange slider) then restart homebridge and get me the log entry the plugin shows like in your original message?

Ignore my previous (now deleted) comment.
Can you update to the beta version of the plugin, 8.9.2-beta.1, and see if the light works?
https://github.com/bwp91/homebridge-ewelink/wiki/Beta-Version
Let me know!

Hi @bwp91
Thank you. It works now.
Im new in homebridge (1st use yesterday) and checked only on/off func.
Thanks again for quick reply and help

Once you’re setup in the home app do check brightness and colour control too!

Once you’re setup in the home app do check brightness and colour control too!

For check this I should to select one of the devices in the devices list in the Settings->Light Devices, right?
I didnt see my device in the dropdown list.

I checked in apple home app on ios brightness and color selection and it works. Can I manually add a circle with my own light or RGB circle?

You can’t add more circles, you only have the adaptive lighting (?) one and the five others which you can change to your own personal colours.

You can’t add more circles, you only have the adaptive lighting (?) one and the five others which you can change to your own personal colours.

Ok thank you for reply. Adaptive lighting appears on home app. Didn't use yet.


Unable to receive any new messages

Hi @aler9 ,
Firstly, thank you for creating such a useful library. I would like to express some of the issues I am currently facing when using this library. Currently, I have a ROS environment (ROS Kinetic on Ubuntu 16.04) on my robot subscribing to a topic called '/cmd_vel'. On the server end, I have a Windows environment with Golang (Windows 10 Pro, Go 1.15.3), responsible for publishing the topic '/cmd_vel'.
I firstly did a roscore on the client side (robot), with the IP of <IP_ADDRESS> and port of 11311. I edited the following script such that this Golang script publishes 'geometry_msgs.Twist' message on the server side to the robot. Content published is displayed on the terminal. However on the client side, I can see the topic being published when i did rostopic list -v, but when I performed a rostopic echo /cmd_vel, it is an empty message. rostopic hz /cmd_vel indicates that no new mesage is coming in, which implies that the initial 'handshake' is established but somehow messages are being dropped. Additionally, the published topic does not go away in rostopic echo /cmd_vel even when I had stopped publishing from server side.
When I attempted to subscribe to another topic from server (Golang), there is no new message received as well. Here is the code I executed on Windows. Let me know if you have any insights to this issue, thanks!
func RosSending() {
	// create a node with given name and linked to given master.
	n, err := goroslib.NewNode(goroslib.NodeConf{
		Name:          "goroslib_pub",
		MasterAddress: "<IP_ADDRESS>:11311",
	})
	if err != nil {
		panic(err)
	}
	defer n.Close()

	// create a publisher
	pub, err := goroslib.NewPublisher(goroslib.PublisherConf{
		Node:  n,
		Topic: "/cmd_vel",
		Msg:   &geometry_msgs.Twist{},
	})
	if err != nil {
		panic(err)
	}
	defer pub.Close()

	// publish a message every second
	ticker := time.NewTicker(2 * time.Millisecond)
	defer ticker.Stop()

	for range ticker.C {
		msg := &geometry_msgs.Twist{
			Linear: geometry_msgs.Vector3{
				X: x,
				Y: y,
				Z: z,
			},
			Angular: geometry_msgs.Vector3{
				X: ax,
				Y: ay,
				Z: az,
			},
		}
		fmt.Printf("Outgoing: %+v\n", msg)
		pub.Write(msg)
	}
}

Hello, i tried to replicate the issue, but in my case everything worked flawlessly. I did the following:

on the first pc, which is running Ubuntu 20.04 and has ROS Noetic installed, i started the master
roscore

on the 2nd pc, which is running Windows 10 20H2, and has Go 1.15.3 installed, i downloaded your script and started it
go run main.go

on the first pc, i started rostopic echo
rostopic echo /cmd_vel

and i was able to correctly see the periodic messages
---
linear:
  x: 1.0
  y: 2.0
  z: 3.0
angular:
  x: 4.0
  y: 5.0
  z: 6.0
---

In my opinion, it could be a firewall problem, since

rostopic list requires a connection with the master only, not with the publisher
rostopic echo requires a connection with the publisher

so try disabling firewall on both sides.

Hi @aler9 ,
Thank you so much for the detailed explanation. I should have clarified this earlier; we actually used an Ubuntu virtual machine (Ubuntu 16.04) hosted on Windows via Virtual Box. This is used to communicate with the windows computer with Golang installed.
Unfortunately, we attempted to disable firewalls on both the server and client sides (on both windows platform and the Ubuntu VM), but the issue persisted. Would you think this issue is related to the VM? We are sure we the Windows environment with Golang could ping the ubuntu VM.

Hi @aler9,
I retested this setup on Ubuntu 18.04 on ROS Melodic and both publishing and subscribing with GoRosLib works. Thanks for your help!


Draft: make Config receive LLM objects

see background here: https://github.com/continuedev/continue/pull/317#issuecomment-1654904324
this is a draft for feedback, code is at the moment very broken.
the idea is to pass LLM objects into the config, to do that we have to:

[x] split api_key reading away from class initialization. at the moment i created a start/stop async callback for LLM classes to implement. this lets the concern of which model string goes to which env var be inside the respective LLM class

this would also let the GGML class store its own AsyncSession instead of continuously creating one on every action

immediate pro: it's what aiohttp wants, see https://docs.aiohttp.org/en/stable/client_quickstart.html: Don’t create a session per request. Most likely you need a session per application which performs all requests together. [...] A session contains a connection pool inside. Connection reusage and keep-alives (both are on by default) may speed up total performance.
future pro: socks5 proxy (who knows what the future may provide, but that won't be implemented here.)

[x] pass sdk object to llm classes so they can access secrets
[x] make api key be fetched declaratively by LLM instead of passing sdk object
[ ] fix plugins making explicit references to specific models like gpt35 or starcoder. reference only the configured model (multiple model support sounds like a good idea, so you could use gpt3.5 for some task, and WizardCoder-GGML for another, but that can be done after this PR)
[x] multi model support (small/medium/large model roles)
[ ] refactor llm attributes left over in util-type files and put all into LLM class

prices, max tokens, chat capabilities, etc

[ ] replace plugins calling hardcoded models (gpt35, starcoder, etc, just review all models accesses) to call the respective model role

gpt35 becomes medium
starcoder becomes medium
gpt4 becomes large

[x] make MaybeProxyOpenAI LLM class, use it in default_config
[ ] turn GGML's aiohttp.AsyncSession into an instance attribute
[ ] fix SDK get_api_secret not using prompt (maybe by removing it entirely?)
[ ] ???
[ ] profit

My idea on this is something like "model roles."

I didn't understand the separation between small/medium/large, but "summarizer" is a good role already for something like GPT-3.5. Could you elaborate on what custom would mean on that example?

My idea on this is something like "model roles."

I didn't understand the separation between small/medium/large, but "summarizer" is a good role already for something like GPT-3.5. Could you elaborate on what custom would mean on that example?

Small/medium/large just meaning larger/slower vs. smaller/faster models. Seemed a bit more general than "summarizer", because gpt35 can be used for other tasks as well. Custom should exist because for example the small/medium/large/default might not be enough slots for all the LLMs someone wants, or at least it could be limiting. Or let's say they have their own super specific LLM that is used in a custom Step they've written. Then they'd want to be able to reference it with sdk.models.custom["my_custom_model_name"].

the small/medium/large/default might not be enough slots for all the LLMs someone wants, or at least it could be limiting.

I don't understand how would a custom model be used from the perspective of the code that already wants models.large, I can understand mapping for a custom Step, but that reads as if it's a separate example than the first sentence. If the intention was just to provide custom Step support, that's fine, and I apologize for misunderstanding.

the small/medium/large/default might not be enough slots for all the LLMs someone wants, or at least it could be limiting.

I don't understand how would a custom model be used from the perspective of the code that already wants models.large, I can understand mapping for a custom Step, but that reads as if it's a separate example than the first sentence. If the intention was just to provide custom Step support, that's fine, and I apologize for misunderstanding.

No worries—I think there's a good point here: you can still get custom LLMs that aren't in sdk.models.small/medium/large/default by just importing it yourself into a custom step. So let's remove the custom thing in Models, but keep small/medium/large:
config = ContinueConfig(
...
  models: Models(
    default=OpenAI("gpt4",...),
    small=OpenAI("gpt-3.5",...),
    large=None,  # This would fall back to the default model (these are all optional kwargs, except default)
  )
)

I'm taking a longer look into what's going to be needed to make this ready and it seems like it is a very large refactor job... I don't see an avenue where both "LLM objects in config" can come without "very big PR", any ideas? I left some TODOs in the current PR that show points where future work can happen

I'm okay with big PR to be honest. I think the general direction is great, and had expected a bit of cleanup would be needed around the LLM classes. I'll make a few edits myself tomorrow to try and pull this through, then do a bit of testing.

Working on this now. Next will make a commit so that all references like sdk.models.gpt35 use sdk.models.default/small instead

@lun-4 I'm going to stop here to let you take a look, but afterward I'd like to merge main to here and test a bit. Pretty excited about this PR because it sets up to allow easily running llama2 with Continue!

Thank you very much! I had the maybe-proxy already written up on my machine, but completely forgot to commit, oops!

^and thanks for cleaning up those few things. All clear to merge main into this branch?

I believe we have a PR ready for merge! Feel free to add any other tweaks, then give me a thumbs up and I'll click the button 🚀  : )

woo! 🎉 congrats on a great PR, and thanks for such great attention to detail!


Add Outfox Ice

Outfox Ice is a single-hue based scheme, somewhere around 218°, which gives an ice-like color.
Alongside this, I have also added a credits file, since otherwise, this could be confused for the same person making multiple schemes.

Thanks for the credits file, I forgot about that, you can create a README.md inside your Ice folder to showcase it's color in specific screens if you want, if you do not wish to do so, just mention when I should merge.

The conflict is in the sight difference between the README in this repo and the one in mine that fixed a slight error ("Discord like" vs. "Discord-like").


issue in truth table generator

i would like to work on this as i can make it more attractive using html and css under SSOC

#787

I've work experience of front end tech in a startup as a Intern. Pls allot this issue to me!

Describe the issue in detail @Swapnalighadge

i can add attractive background and i can change the button style and font  of  truth table generator

@TusharKesarwani please provide me with this opportunity as I've real time hands on practice in Web Technologies. Will surely contribute to the best of my knowledge.

#787

@TusharKesarwani i have added description #787


wrong result

http://sha1affected.com/results?server=isotopeecommerce.org
The certificates for isotopeecommerce.org do not contain SHA1 signatures and won't be affected.
Sure?
End Identity	*.isotopeecommerce.org, isotopeecommerce.org	2016-06-26	SHA1

Something isn't right there. I'll get a look at it over the next 24hrs. But you're right, it's a bug and thanks for the report.

This has been resolved.
It was quite a bad mistake, I hadn't come across a SHA1 certificate with a SHA2 intermediate, so the code overwrote the fact it was SHA1 when looping through the certificates. I don't love this code.
Thanks again.

You are welcome. Thanks for fixing this so fast.


I need FancyZones to work

Microsoft PowerToys version
0.67.0
Installation method
GitHub
Running as admin
Yes
Area(s) with issue?
FancyZones
Steps to reproduce
Fancy Zones not running after reset in Win 11
✔ Expected Behavior
FancyZones to work
❌ Actual Behavior
FancyZones not working
Other Software
No response

Can you please specify the problem? Does it happen after moving the window to a second monitor using Win+Arrow?


Show new version bar when build hash changes

Summary

This pull requests switches displaying the "new version available" announcement when the config's BuildHash changes instead of the server version.
This change is needed for community the current check of server version takes into account MAJOR.MINOR.PATCH.BUILDNUMBER parts of the server version, and BUILDNUMBER for community is always master, so the announcement bar is not displayed as it should.
Ticket Link

https://mattermost.atlassian.net/browse/MM-45934
Release Note
NONE

/check-cla

/release-note-none

/check-cla

E2E tests not automatically triggered, because PR has no approval yet. Please ask a developer to review and then try again to attach the QA label.

/e2e-test

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/230492


Use Java 17 in readme

This project requires Java 17 (not 11) and a version of Maven which runs in Java 17

Thank you so much for this.

No problem. I have more coming but I'll only push that once I have the system running properly :)


Update content

:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

xml/Microsoft.ServiceBus.Messaging/SubscriptionClient.xml
:white_check_mark:Succeeded

xml/Microsoft.ServiceBus.Messaging/TopicClient.xml
:white_check_mark:Succeeded

xml/Microsoft.ServiceBus/NamespaceManager.xml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Figure out how to get the original parameter names in the generated APIs

I think this means rebuilding Vert.x with different javac options before doing java.reflect things to it

Fixed by using an annotation processor to generate the code


CachableFlash::Middleware not working

I've tried swapping the Cacheable Flash middleware in using the instructions in the README but it doesn't seem to be working for me. Unfortunately, it's also not giving me any errors. Is there anything I need to do beyond adding "config.middleware.swap ActionDispatch::Flash, CacheableFlash::Middleware" to my application.rb?

Please consider switching to https://github.com/leonid-shevtsov/unobtrusive_flash


PHP 8.1 - after instalation via dockerifle - deprecated messages

after instalation cachetool via dockerfile (php:8.1-fpm)
&& curl --fail -sOL https://gordalina.github.io/cachetool/downloads/cachetool-8.0.2.phar && chmod +x cachetool-8.0.2.phar && mv cachetool-8.0.2.phar /usr/local/bin/cachetool \
it shows deprecated messages:
Deprecated: Return type of HumbugBox3100\KevinGH\RequirementChecker\RequirementCollection::getIterator() should either be compatible with IteratorAggregate::getIterator(): Traversable, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///usr/local/bin/cachetool/.box/src/RequirementCollection.php on line 12
Deprecated: Return type of HumbugBox3100\KevinGH\RequirementChecker\RequirementCollection::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in phar:///usr/local/bin/cachetool/.box/src/RequirementCollection.php on line 16

Blocked by https://github.com/box-project/box/pull/578

@gordalina it seems to be already merged...

Blocked by https://github.com/humbug/php-scoper/issues/539

humbug/php-scoper has new version, so probably problem is already fixed?

@thorewi @beeyev can you test this build? https://github.com/gordalina/cachetool/releases/tag/8.3.1-alpha.0

@gordalina working like a charm! thank you.

Released in 8.4.0


Support TypeScript 3.8

Can't use the new type imports introduced by TypeScript 3.8
SyntaxError: /Users/levrik/code/<redacted>/src/theme.ts: Unexpected token (3:12)

  1 | import { createMuiTheme, emphasize } from '@material-ui/core/styles';
  2 | import createPalette from '@material-ui/core/styles/createPalette';
> 3 | import type { SkeletonClassKey } from '@material-ui/lab/Skeleton';

https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-8.html#type-only-imports-exports
react-script 3.4.0
TypeScript 3.8.0

This is now included thanks to #8681

Closed by #8681

This should be available in<EMAIL_ADDRESS>


Hide the settings button if the settings route was already opened

Fixes #41.

I don't think we need to update goldens here

I don't think we need to update goldens here

I added a new golden test, the rest is just noise.

Hm, looks like the goldens are still producing different images, even though I can't see a difference anymore. That's annoying.

Hm, looks like the goldens are still producing different images, even though I can't see a difference anymore. That's annoying.

If you mean that goldens are different each time, yeah, this is annoying


where is the server.pfx file?


liboqs: 0.10.0 -> 0.10.1

Description of changes

Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

Please remove open-quantum-safe/liboqs@f0e6b86 patch, it's already in 0.10.1

This is a patch that is reverted

Please remove open-quantum-safe/liboqs@f0e6b86 patch, it's already in 0.10.1

This is a patch that is reverted

Oh, I see.


Limit value length of metadata fields to max 255 chars.

The current database scheme has varchar(255) for several metadata types. Traditionally, MySQL would just truncate silently any too long values. Modern installations have strict mode enabled which instead generates a justified error. To make EB usable in this configuration, limit the length of some fields that (a) have a trend to sometimes be long, (b) which can be truncated without real loss.
One could consider to enlarge columns but as far as I'm aware description is not used and 255 chars of keywords should be enough for everyone. So for now lets keep it to this simple fix.

I have implemented the feedback, will square after review


write tests for get_next_chant(), and fix related bug

This PR adds several tests for the Chant model's .get_next_chant() method.
In writing them, I found a bug in the implementation of .get_next_chant(), which this PR also fixes:

In situations where one or several pages of the manuscript have been lost, this is usually indicated by a "LACUNA" chant record, with a sequence_number of 99 on the last folio before the lacuna. .get_next_chant now accounts for gaps in the numbering such as this.

This bug fix is necessary for a future to the populate_next_chant_fields admin command, PR forthcoming in the next couple of days.
The code for .get_next_chant is starting to become a bit complicated, so it should probably be refactored sometime soon.

I think what I was thinking was that there may be weird interactions if there is only one chant on a folio, and the folio doesn't have a set of chants with sequential sequence_numbers. But I should have made for loops to make the intention clearer. In any case, I don't think it's necessary, so I just got rid of the extraneous additional chants - it's simpler/cleaner this way.


Recaf deadlock changing recompilation target version from class view popup

Describe the bug
When attempting to modify the recompilation target version via the gear menu in the lower-right of the class view, recaf deadlocks.
To Reproduce
This reproduction was tested with multiple .jar files and multiple classes within those .jar files.
One thing in common all .jar files had was they were Minecraft 1.7.10 mods.
Steps to reproduce the behavior:

Open workspace.  Reproduction tested with Railcraft_1.7.10-<IP_ADDRESS>.jar.zip
Navigate to any class
Select gear icon in lower-right of class view
Try to change "Compile target version" away from "Match class file version"
Recaf deadlocks

Exception
No exception is generated.  JStack output attached in lieu.
(Updated, I accidentally JStack'd the launcher and not recaf)
crash.txt
Screenshots

In the event that this cannot be reproduced, it may also be related to me having multiple files in the workspace at the same time.  Just in case that's so, this is my current workspace, zipped up
Recaf Workspace.zip

Based on the JavaFX Application Thread contents, my best guess is this is some really odd bug caused by the combo-box resizing triggering an infinite scene invalidation loop.
https://github.com/Col-E/Recaf/blob/dev4/recaf-ui/src/main/java/software/coley/recaf/ui/pane/editing/jvm/JvmDecompilerPaneConfigurator.java#L104
In these combo-box classes, can you try adding this to the constructors?
int w = 200;
setMaxWidth(w);
setPrefWidth(w);

The idea is that if we force the combo-boxes to be a uniform size, they won't ever resize and get us into this odd state. I cannot seem to reproduce the issue on my end but this is my best guess as to what should fix it.

I added the hypothetical fix in 65a6ccd0f95170efa00b99e7898ce46c060346bf - If this issue persists just re-open this issue.


Hi, how do you set the scale range for each dimension in the radar chart to be different？

Hi, nice code and picture!
how do you set the scale range for each dimension in the radar chart to be different？

Hi @jingzhengli!
Thank you for showing interest in MaPLe.
Regarding your query, please note that:

The radar chart uses the min and max value in each dimension list for setting the range in the plot.
You can see the python code which we used for generating the radar plot here.

We hope your query is resolved now.
Thank you.

Thanks for your quick and detailed reply. It would completely solve my confusion. I have spent one day to draw such radar chart. Thanks again~

No problem. Best of luck for your work!

No problem. Best of luck for your work!

Hi, I compared the time consumption  of some methods. I found that the running time in forward pass and backward propagation in MaPLe (0.281s) is lower than CoOp (0.558s) and CoCoOp. It is very interesting and I wonder if there is something wrong with my experiment?
I guess the reason is that MaPLe only updates the top-level and middle-level parameters, while CoOp updates the bottom-level parameters such that it consumes more time.

Hi @jingzhengli,
In comparison with CoCoOp, both MaPLe and CoOp are much faster during training because of the feedback image conditional signal in CoCoOp.
But in comparison between MaPLe and CoOp, I believe MaPLe should take a bit more time during backward pass as it updates the prompts in both vision and language branches of CLIP while CoOp only does it for the language branch.
So, I think we can verify this experiment again which you are performing. Can you take a look into the following items:

Are you doing comparison with keeping the batch size same? It should be noted that the default batch size of MaPLe is 4 while for CoOp, I think it is 32.

Are you calculating time for only one single forward and backward pass, or are you running multiple runs and then taking the average? Some times, there can be random delays. So you can try running a for loop for to undergo multiple forward and backward passes and then take the average time. It might reduce the effect of the random delays that could possibly occur.

I hope this can be helpful.
Thank you and kind regards

Hi @jingzhengli,
In comparison with CoCoOp, both MaPLe and CoOp are much faster during training because of the feedback image conditional signal in CoCoOp.
But in comparison between MaPLe and CoOp, I believe MaPLe should take a bit more time during backward pass as it updates the prompts in both vision and language branches of CLIP while CoOp only does it for the language branch.
So, I think we can verify this experiment again which you are performing. Can you take a look into the following items:

Are you doing comparison with keeping the batch size same? It should be noted that the default batch size of MaPLe is 4 while for CoOp, it is 32.
Are you calculating time for only one single forward and backward pass, or are you running multiple runs and then taking the average? Some times, there can be random delays. So you can try running a for loop for to undergo multiple forward and backward passes and then take the average time. It might reduce the effect of the random delays that could possibly occur.

I hope this can be helpful.
Thank you and kind regards

Hi @jingzhengli,
In comparison with CoCoOp, both MaPLe and CoOp are much faster during training because of the feedback image conditional signal in CoCoOp.
But in comparison between MaPLe and CoOp, I believe MaPLe should take a bit more time during backward pass as it updates the prompts in both vision and language branches of CLIP while CoOp only does it for the language branch.
So, I think we can verify this experiment again which you are performing. Can you take a look into the following items:

Are you doing comparison with keeping the batch size same? It should be noted that the default batch size of MaPLe is 4 while for CoOp, it is 32.
Are you calculating time for only one single forward and backward pass, or are you running multiple runs and then taking the average? Some times, there can be random delays. So you can try running a for loop for to undergo multiple forward and backward passes and then take the average time. It might reduce the effect of the random delays that could possibly occur.

I hope this can be helpful.
Thank you and kind regards

Sorry for the late reply, due to the experiment.
Thanks for your insightful perspective. You are right: MaPLe takes a bit more time than CoOp.
I additionally have some new findings. Despite the fact that the prompt-based methods (i.e., CoOp, CoCoOp) require only a small number of trainable parameter to be updated, they consume more time than other fine-tuning methods (i.e., Full fine-tune, linear-probing). In other words, Fewer trainable parameters can reduce the training memory, but not necessarily improve time efficiency. I don't know if this is the correct view. Thanks for your kind consideration.


Depfu/batch all/2020 07 18 + Race condition fix

Depfu changes plus fixing the race condition triggered in its last build.

Possibly unrelated to your changes, but, I just noticed it's modifying the same file as we had some issues with recently. See pull request https://github.com/sanger/sequencescape/pull/2853/files, where a couple of changes were made to this file. They don't seem to be displaying in your pull request? (If you click the up arrow on the diff to show more of the file). Is this just Github's diff being buggy, or is there something wrong?

Regarding the diffs. I think this branch was forked off before your changes were made (I based it directly on depfu's branch) hence why the other changes aren't showing. It also wont show up in diffs as:
https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-comparing-branches-in-pull-requests

By default, pull requests on GitHub show a three-dot diff, or a comparison between the most recent version of the topic branch and the commit where the topic branch was last synced with the base branch.
So the diff isn't agains HEAD.

Ah that's useful to know, thank you. I think Bitbucket shows you the diff between the current base branch and the topic branch (https://blog.developer.atlassian.com/a-better-pull-request/) - so that's what I'm more used to.


[pkg/queue] Provide factory for consumers

Requirement - what kind of business use case are you trying to solve?

As stated in open-telemetry/opentelemetry-collector#2254 for performance reasons we want to be able to keep state for each consumer of a bounded queue so that we can reuse a certain struct.
Problem - what in Jaeger blocks you from solving the requirement?
It's not currently possible to define a state for each consumer of a bounded queue: the public interface for the bounded queue only allows for providing a function and every consumer runs that function, so you can only keep a global state for all consumers.
https://github.com/jaegertracing/jaeger/blob/1b209472dc6a35f7de90c7a9048cb4e960cc2335/pkg/queue/bounded_queue.go#L61
Proposal - what do you suggest to solve the problem or improve the existing situation?
A possible solution would work like this.

Define an interface like

type Consumer interface {
  Consume(item interface{})
}

Provide a new way to start a bounded queue with signature

func (q *BoundedQueue) StartConsumersWithFactory(num int, factory func() Consumer)

Reimplement consumer logic internally so that each consumer is built using the factory.

Rewrite StartConsumers using this factory

type statelessConsumer struct{
  consumefn func(item interface{})
}

func (c *statelessConsumer) Consume(item interface{}){
  c.consumefn(item)
}

func (q *BoundedQueue) StartConsumers(num int, consumer func(item interface{})) {
  consumer := &statelessConsumer{consumer}
  q.StartConsumersWithFactory(num, func(){
    return consumer
  })
}

Any open questions to address
I think this would keep backwards-compatible behavior with minimal/no impact to performance but I am not a Go expert so that should be double-checked.

Can you give some concrete examples of what you need to accomplish? It's a bit too abstract for me to understand if this would be suitable to other consumers of this package.

Can you give some concrete examples of what you need to accomplish?

Sure! I can try to explain our current use case if that helps.
When we process traces in the Datadog exporter we use a struct called SublayerCalculator to get some information about each trace. This struct has a ComputeSublayers method that resets the struct (fills a bunch of bytes slices with zeros) and then computes some info about traces. We need to do this computation for every trace, and the struct is somewhat costly to create (so we can't just allocate a new one for each batch of traces).
Right now we use one SublayerCalculator (behind a mutex) for the whole exporter, so, whenever any consumer wants to compute the sublayers, it has to lock the mutex. The mutex contention reduces throughput of traces under high load conditions.
What we would want is for each consumer to have its own SublayerCalculator. That way each consumer could function independently and we could increase throughput under high load.
Other consumers of this package might want to do this for similar reasons: keeping some state per-consumer to avoid allocations or using a mutex.

I think I understand what you want to do wrt to the queue itself, but why do you need to make changes in Jaeger?

@yurishkuro This package is used in the OpenTelemetry project (in particular in the OpenTelemetry Collector). I am sorry I did not give more context in my second message, @jpkrohling also contributes to this project so I skipped over some details.

To clarify, my concern is that this creates a twice-removed dependency on an implementation detail in Jaeger. OTEL collector is once-removed, and from the ticket they don't need this enhancement, so it's only DD exporter which needs it, and as I understand it's not a core component in OTEL Collector, thus twice-removed. The /pkg does not extend any stability guarantees outside of Jaeger projects, I'm even surprised that OTEL is depending on it explicitly.
I think your proposal is reasonable and fairly minimal, I don't have strong objections to extending the queue this way. It will need unit tests with comments about external dependency, which will help a bit with stability against refactoring.

The /pkg does not extend any stability guarantees outside of Jaeger projects, I'm even surprised that OTEL is depending on it explicitly.

Ah, I wasn't aware about that, thanks for the clarification. I assumed since OTEL was using it it was fine to use outside of Jaeger. If you are okay with keeping the dependency, I would be willing to open a PR for this. Once released our intent would be then to use this in the OTEl Collector directly if a change is accepted there and otherwise use it only in the Datadog exporter.

@jaegertracing/jaeger-maintainers PTAL

I generally think it's fine as long as @mx-psi is fine with the taking on the risk of depending on this package.  In practice it probably won't change much, but we know how that goes.  Perhaps it would be easier to fork the queue if there will be more changes to come?  It's not a ton of code and if you need a lot of specialized behavior that could be easier in the long run.
This particular change looks like it can be done in a safe way that has minimal impact to the Jaeger codebase so I think it's acceptable.

One thing we need to consider is the changes that will occur for jaeger v2 - so better if it wasn't dependent upon this pkg.

I generally think it's fine as long as @mx-psi is willing to take on the risk of depending on this package. In practice it probably won't change much, but we know how that goes. Perhaps it would be easier to fork the BoundedQueue if there will be more changes to come? It's not a ton of code and if you need a lot of specialized behavior that could be easier in the long run.

I think we are fine with that, we don't plan on making further changes and if the Jaeger project needs to make significant breaking changes on this package we can always fork later.

One thing we need to consider is the changes that will occur for jaeger v2 - so better if it wasn't dependent upon this pkg.

@objectiser note that this package is already a dependency of the OpenTelemetry Collector (see here). If that is a concern, maybe you should open an issue on the OTEL repo to remove the dependency or at least make maintainers aware of the lack of stability.

IMO, if we have something as part of pkg, Go conventions "dictate" that others can consume and expect semver compatibility. I wouldn't have added a dependency just because of this queue, but it's out there already.
For v2, we should place things like this in an internal package, preventing go mod from adding such dependency.

The main reason we have avoided using internal packages is that Uber's internal builds are cherry-picking quite a lot of different components, and I definitely ran into issues trying to move some stuff under internal. So we kind of opened that can of worms.

Hi, I am not sure what the outcome of this discussion is in the end. Are Jaeger maintainers okay with a PR for this issue? Should the OpenTelemetry Collector fork the queue package and I can discuss the changes there?

Feel free to post a PR, I don't think it makes things worse given that we already have the dependency.


Fix Window.set_inner_size() on win32

Previously, the function would actually set the outer size of the window instead of the inner size.
We fix this by first letting windows calculate the outer size based upon the specified inner size.

Thanks!

I see that you have published a new version (0.3.7) to crates.io. However, this fix seems not to be included. Have you published it without having the latest master locally?

@mvdnes Yes, master contains breaking changes already, so this change will be in version 0.4.0.
The version 0.3.7 was an urgent fix because of a problem of semver in gl_generator. I took version 0.3.6, applied the fix, and published.

A ok no problem! It was just a bit confusing since there are no indicators in the git repo (that I am aware of).


qcom: make camera_process_frame more readable

going to split camera_process_frame into smaller functions

looks good so far. Is it ready to merge?

Not ready yet, I'll do more checks after rebase master


Add scaled quantile loss

Description of changes: Add scaled quantile loss, also known as scaled pinball loss, which is used for example in the M5 competition https://mofc.unic.ac.cy/m5-competition/. This just scales the quantile loss by the average naive error, similar to MASE.
$$
sQL_\alpha(\hat y, y, x) = \frac{
QL_\alpha(\hat y, y)
}{
\tfrac{1}{T-S} \sum_{S < t \leq T} |x_{t} - x_{t-S}|
}
$$
where $S$ is the number of seasons ($S=1$ gives the MAE of the naive forecaster in the denominator). This is aggregated via mean over the prediction length and/or dataset dimension. Reduces to MASE when the quantile level is 0.5.
I went for "quantile" instead of "pinball" for consistency with other metrics we have. Naming is not ideal, especially when we want to average over multiple quantile levels (AverageMeanScaledQuantileLoss), I'm open to suggestions.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.
Please tag this pr with at least one of these labels to make our release process faster: BREAKING, new feature, bug fix, other change, dev setup

I'm wondering if we should use "Seasonal" or "Relative" somewhere in the loss instead of scaled. Currently, it's a bit confusing.

I like "relative" better, but I agree that consistency with MASE and how this type of (indeed relative) metric is called elsewhere.


Move the terraform code to Cloudformation and ansible

Need to implement the task to maintain unanimity across the platforms using a maximum mutually exclusive tech stack plays a key role.

Latest changes have been merged and tested, closing!


Can not launch

Hi,
Sometimes, i received this kind of fingerprint and my application can not launch and it prints:
undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined
undefined
Erreur lors de l'execution de l'impression: fingerprint :  Error: Timed out while calling the "setup" method.
at Timeout._onTimeout (C:\Users\ramia\node_modules\browser-with-fingerprints\src\plugin\connector\index.js:34:26)
at listOnTimeout (node:internal/timers:564:17)
at process.processTimers (node:internal/timers:507:7)
my code:
const { plugin } = require('puppeteer-with-fingerprints');
const main = async () => {
const fingerprint = await plugin.fetch('my_key');
plugin.useFingerprint(fingerprint);
const browser = await plugin.launch({
headless : true
});
const page = await browser.newPage();
await page.goto("https://ipleak.net/");
}
main()

Sharing fingerprints is prohibited. If you continue do that, your key will be blocked.

Sorry , i forgot

after rebooting my computer, i dont get the error. Maybe it was a problem of internet connection


  Pretty much all of these points are described in much more detail in PlasmaPy's documentation guide.

Added api_static pages for each module.  These are needed for modules to show up in the documentation (described in PlasmaPy's documentation guide)
Created a file to include reStructuredText links (docs/_links.rst)
Created a file to include reStructuredText substitutions (docs/_substitutions.rst)
Updated the index page.
Begin a getting started page (docs/getting_started.rst)
Added an example notebooks page (docs/examples.rst) and directory (docs/notebooks) with some example galleries.  This is built using nbsphinx.
Added a units notebook that was adapted from PlasmaPy
Added a sparse bibliography page (with bibtex entries in bibliography.bib).  Closes #34.
Added an empty glossary page
Updated the setup for intersphinx, which allows us to link to objects in other Python documentation pages
Added/configured a bunch of Sphinx extensions (see extensions in docs/conf.py)
Added a few docstrings to make the documentation build work (which might lead to a merge conflict with #33)
Modified a few imports and some __all__ lists that were making the documentation build grumpy
Updated the documentation tox testing environments (including using the "nitpicky" open which will help us identify broken reStructuredText links before they pile up...not that that happened with any other projects I'm working on 😅). This follows up on #37.
Updated some of the requirements, following up on #39.
Added some CSS files from PlasmaPy which had been adapted to improve accessibility & color contrast.
Changed the theme to sphinx_rtd_theme

When doing a test build of the docs with tox -e build_docs, I started getting an error that a .genx file couldn't be found.  My best guess is that this isn't related to the documentation but has more to do with the package itself.

This is looking just about ready.  I was able to copy/adjust most of the setup from PlasmaPy, so it was pretty straightforward.
There are still some test failures because xrtpy isn't able to find a .genx file that it needs.  These test failures were hidden because the full test suite was not being run.  This is causing the documentation builds to fail here, though I was able to get the docs to build locally.  The linters and codespell checks are related to code that's being worked on in #33, so making those changes could end up leading to a messy merge conflict.  In any case, it doesn't look like the test failures are related to this pull request, and we should be able to address them in #33.


Publishing incomplete articles for the new Status app

Problem:
Writers don't have yet all the answers for the upcoming Status app. This makes it difficult to create final content.
Proposed solution:

To publish in our master Status Help branch draft versions of our articles.
Notify readers that these articles are not final (and most probably, not accurate)
Set up a process to track and update these articles as new Status app updates get released.

For further discussion, see this Notion page

I've created the folders and placeholder files for the Join a Status Community topic to test icons and admonitions on mobile view.
Conclusions:

Using Material for Mkdocs Tooltips, like in :octicons-beaker-24: [Experimental](title="This article refers to an experimental feature. This information may be incomplete or not work as expected.") renders the tooltip correctly when hovering over "Experimental" but creates a broken (404) link when clicking on the "Experimental" word. Not ideal 🙁

An option would be to link to the same article, but this seems misleading from a usability point of view. This behavior gives the impression that the link is broken.

Looking at the Material for MkDocs documentation on tooltips, it doesn't seem possible to avoid the hyperlink. We can only omit the hyperlink when adding the tooltip to the icon, but this is not visible. The user must hover over the icon and wait for the tooltip to show up for a second. It isn't convenient.

Code: :octicons-beaker-24:{ title="This article refers to an experimental feature. This information may be incomplete or not work as expected." } Experimental

For this particular case, Annotations are probably a better option than tooltips. The downside is that they introduce non-native Markdown code that will only work on a platform supporting py-Markdown, (like Material for MkDocs).

Code:

:octicons-zap-24: New · :octicons-beaker-24: [Experimental](title="This article refers to an experimental feature. This information may be incomplete or not work as expected.")

---
:octicons-zap-24: New · :octicons-beaker-24: Experimental (1)
{ .annotate }

About admonitions, we only use them for the "In progress" articles.
Testing the Admonition without title seems to work. We can customize the admonition look-and-feel further via Material for Mkdocs CSS settings (see example here).
The drawback is that the Admonition (and Annotations) text is probably too small. There seems to be a way to control these settings in Material for MkDocs, though (see this Discussions thread).

Test published in https://dev-help.status.im/en/status-communities/join-a-status-community/ via https://github.com/status-im/help.status.im/pull/166.
@exebeeche, what do you think?

Superseded by https://github.com/status-im/help.status.im/issues/218.


tests: test CRD versions

Add test which checks if the CRD versions defined in the cluster match the versions in the subcharts in the git repo.
This test ensures that the subcharts in the release version don't unexpectedly change their API versions within a minor Harvester release.
To implement this test, additional infrastructure for the Kubernetes API has been added.
fixes: https://github.com/harvester/tests/issues/1314

Test target and classification are importan, we should not mix different purpose test code.
However we want to automate tests rather than manual, (of course we can keep both of them for specific timing of test.)
Should we have this automation in another folder or something thus not break test organization?

IMO, the library apiclient is focusing for Harvester and related endpoint, we don't and will not have plan to implement kube APIs, as it already have many other libs does.

Well, it does not. There's also a Rancher API client part in it.
I also don't just need a generic K8s client, I need a K8s client library where I can just give it a Harvester endpoint, username and password and it deals with the authentication. This isn't the case for normal K8s API client libraries (as you can tell, because I've had to implement that part).

and as Albin's snippets, it shows we can simply get those CRD info from bash, so I would prefer use that version rather than create a new API set.
It would be more readable and fit our manual test steps.

Please no. We have a test suite, let's not add a second test suite.
Bash is also a terrible choice for maintaining any significant amount of code, since it quickly becomes very hard to read.

and I don't think we need to verify those CRDs every time, usually we will only verify them after the cluster upgraded into new version, so we will not place then in apis.

I see your point, but I don't see where else in the test suite an appropriate place would be. Maybe we should create a separate directory for upgrade tests under harvester_e2e_tests/upgrade?

IMO, the library apiclient is focusing for Harvester and related endpoint, we don't and will not have plan to implement kube APIs, as it already have many other libs does.

Well, it does not. There's also a Rancher API client part in it. I also don't just need a generic K8s client, I need a K8s client library where I can just give it a Harvester endpoint, username and password and it deals with the authentication. This isn't the case for normal K8s API client libraries (as you can tell, because I've had to implement that part).

and as Albin's snippets, it shows we can simply get those CRD info from bash, so I would prefer use that version rather than create a new API set.
It would be more readable and fit our manual test steps.

Please no. We have a test suite, let's not add a second test suite. Bash is also a terrible choice for maintaining any significant amount of code, since it quickly becomes very hard to read.

and I don't think we need to verify those CRDs every time, usually we will only verify them after the cluster upgraded into new version, so we will not place then in apis.

I see your point, but I don't see where else in the test suite an appropriate place would be. Maybe we should create a separate directory for upgrade tests under harvester_e2e_tests/upgrade?

We will not implement all Rancher APIs, we would only implement those parts related to Rancher Integration, so the RancherAPI is not be included by default.  and we have VCluster addon to enable embedded Rancher, so it is make sense to have the API client.
This repo is for test automation, not a product to modify frequently.  For test automation, readability, simply and manually reproducible are important than others.  That's why I would prefer to have a bash version and not include another library, less dependencies would let us more easily to address the root cause when test fails.
Ideally, we will check CRD versions after cluster upgraded, so the automation test cases should be placed into upgrade.


Binary wheel for python3.9

Hi. Can you please kindly add python 3.9 support for the pypi linux wheel?

I've added this, thanks for requesting. I think I had tried this before, but I hadn't updated my manylinux image. Anyways, 0.4.5 of pysqlite3-binary should support 3.9 now.

Legend! Thanks 😉


Retry failed integrations if master changes

If integrating an approved pull request fails, either because of a build failure or a conflict, that that is dependent upon whatever master was for that try. If master changes, that should invalidate previous attempts to integrate a pull request.

Likewise, leaving an LGTM comment is currently idempotent and only changes the approval status. That is nice in an ideal world, but in practice it might be useful to clear the integration status, and retry, even if the exact same commit is LGTM'ed again.


Update shared:akka, shared:core, shared:fs2, ... to 1.3.11

Updates

com.softwaremill.sttp.shared:akka
com.softwaremill.sttp.shared:core
com.softwaremill.sttp.shared:fs2
com.softwaremill.sttp.shared:fs2-ce2
com.softwaremill.sttp.shared:monix
com.softwaremill.sttp.shared:ws
com.softwaremill.sttp.shared:zio
com.softwaremill.sttp.shared:zio1

from 1.3.10 to 1.3.11.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.shared" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "com.softwaremill.sttp.shared" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #1644.


Registration Fail, reason  bad_param

{"status":"fail","reason":"bad_param","param":"number"}

@suraj-mahajan full debug log?

@suraj-mahajan you are use virtual number .. make sure this number working fine from provider


Expose timers

Hue has introduced timers few weeks ago. These timers allow to trigger an action (eg light blinks) when a timer ends. Is it possible to expose timers to HomeKit, as switched for instance? Thus, we’ll be able to trigger them with the accessories. Thanks.

Hue has introduced timers few weeks ago. (...) Is it possible to expose timers to HomeKit

That's just the app, the API has supported them for years.  So has homebridge-hue.  By setting "schedules": true in config.json, homebridge-hue exposes an additional custom service for each schedule/timer to the Hue bridge accessory, with a custom Enabled characteristic.  Of course, Apple's Home app doesn't support custom services and characteristics, but other apps, like Eve, do:

If you create a HomeKit scene in Eve, you can activate it from Apple's Home and use it in rules just fine, even when it contains custom characteristics.

as switched for instance

I deliberately use a custom service with a custom Enabled characteristic instead of the standard Switch service and Power characteristic to prevent Siri from inadvertently en/disabling the timers when telling her to switch on/off a room.

Of course. Thanks @ebaauw.

@ebaauw, I have a question that does not concern your plug-in but maybe you can help me.
I have a timer that makes a bulb blink after 2 minutes. When I enable this timer in Eve, the bulb blinks immediately and does not wait for 2 minutes. Is that the expected behavior?

I wouldn’t know.  I only use timers and schedules for scheduled (recurring) events, not for automation events.  I find these are far better handled by rules, using the ddx operator, which allows you to trigger a rule x amount of time after something changed.

OK, thanks @ebaauw.
I have one request (that can be time consuming): can you share with us how you personally use homekit and hue? If you can provide real life examples and how you implement them. For me, it'd be helpful.

I’ve published most of my scripts configuring the Hue bridge (or deCONZ gateway) in ph.sh.  There’s some description in the Wiki.


[CELEBORN-1570] Fix flaky test - monitor non-critical error metrics in DeviceMonitorSuite

What changes were proposed in this pull request?
Why are the changes needed?
https://github.com/apache/celeborn/actions/runs/10441850633/job/28913478820?pr=2692
- monitor non-critical error metrics *** FAILED ***
  java.lang.AssertionError: expected:<2> but was:<1>
  at org.junit.Assert.fail(Assert.java:89)
  at org.junit.Assert.failNotEquals(Assert.java:835)
  at org.junit.Assert.assertEquals(Assert.java:120)
  at org.junit.Assert.assertEquals(Assert.java:146)
  at org.apache.celeborn.service.deploy.worker.storage.DeviceMonitorSuite.$anonfun$new$22(DeviceMonitorSuite.scala:405)

Because calling System.currentTimeMillis() twice may get the same value. Gauge uses the size of the set, and the same value will be deduplicated.
https://github.com/apache/celeborn/blob/0ee3c3a4bdef3b97fca6be04f03ac36c2e12e1a6/worker/src/main/scala/org/apache/celeborn/service/deploy/worker/storage/ObservedDevice.scala#L81-L91
Does this PR introduce any user-facing change?
No
How was this patch tested?
GA

The method System.currentTimeMillis might return the same value for two invokes. I think changing this UT is not the correct approach to fix this problem. Changing the definition of nonCriticalErrors to List will be better.


NzDisabled for NzMenuItem doesn't work

Reproduction link
https://stackblitz.com/edit/angular-oilq9y
Steps to reproduce
Set (click) handler to NzMenuItem which is disabled (via nzDisabled).
What is expected?
The click action should not be executed.
What is actually happening?
Action is executed.

Environment
Info

ng-zorro-antd
11.1.0

Browser
Chrome

I'm sorry, closing as duplicate of #6189


Jruby fixes

A few initial fixes for jruby support (Sequel spec was failing currently).  This should also fix https://github.com/seamusabshere/upsert/issues/61

This will have to wait on #79 for the mysql tests to pass (or I can pull that commit in).

@seamusabshere I tried to get rbx working as well but looks like it's broken (and not really fixable).  I'm hoping travis fixes things on their end soon so we can have it be useful in the build matrix.


Yea i just haven't gotten around to seriously testing or working with mac, help wanted


Seen 4774(F) in the wild

I don't have any authoritative information to add, but I can say with certainty that I have seen an event 4774(F) in the wild. The documentation only mentions a success event, and pretty much says it never happens.
Details on the event in the while can be found here, but the relevant details are:
An account was mapped for logon.

Authentication Package:	Schannel
Account UPN<EMAIL_ADDRESS>Mapped Name:	ACCOUNT

This was an AUDIT_FAILURE, severity ERROR. Task name was "Credential Validation". These events corresponded with audit failure events 6273 (Network Policy Server denied access) and 4771 (Kerberos pre-auth failed) for the same account.

@fluggo thanks for sharing this. I added it to the topic.


[EngSys] Version bump automation is trying to update the wrong file.

KeyVault had a version in src/core/constants.ts. The core folder was supposed to be for generated files only, we didn't have it as such by mistake. This constants file was moved out of that folder into src/constants.ts.

@sadasant : Versioning tool looks for constants file based on configuration in package.json.  Can you please update package.json to point to correct constants file in keyvault packages?
for e.g. path should be updated here for keyvault-keys
https://github.com/Azure/azure-sdk-for-js/blob/348cbeac5204e1f9d24f507f484eb6619854d66b/sdk/keyvault/keyvault-keys/package.json#L79
Please refer this link.
https://github.com/Azure/azure-sdk-for-js/blob/348cbeac5204e1f9d24f507f484eb6619854d66b/sdk/textanalytics/ai-text-analytics/package.json#L38

Looks like this was fixed a while ago. Please re-open if the problem still exists