[stable/rabbitmq] When using minikube and PVC, Liveness and Readiness probes fail

Which chart:
stable/rabbitmq
Description
When using minikube, Persistent Volumes (PV) using hostPath fail when used in stable/rabbitmq chart.  The Liveness and Readiness warnings prevent the pod from reaching a READY state of "1/1".
$ kubectl describe pods --namespace my-namespace my-rabbitmq-0

:
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  :
  Warning  Unhealthy  12s                kubelet, minikube  Liveness probe failed: {"status":"failed","reason":"resource alarm(s) in effect:[disk]"}
  Warning  Unhealthy  6s (x5 over 2m6s)  kubelet, minikube  Readiness probe failed: {"status":"failed","reason":"resource alarm(s) in effect:[disk]"}

The pod launched by the stable/rabbitmq chart never reaches a READY state of "1/1".
Steps to reproduce the issue:

Start MiniKube

minikube start --cpus 4 --memory 8192 --vm-driver kvm2

Install Tiller

kubectl create serviceaccount -n kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:tiller
helm init --service-account tiller

Create namespace.yaml file:

cat <<EOT > namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    name: my-namespace
EOT

Create namespace:

kubectl create -f namespace.yaml

Create persistent-volume-rabbitmq.yaml file:

cat <<EOT > persistent-volume-rabbitmq.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: rabbitmq-volume
  labels:
    type: local
  namespace: my-namespace
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/var/rabbitmq"
EOT

Create persistent volume:

kubectl create -f persistent-volume-rabbitmq.yaml

Create persistent-volume-claim-rabbitmq.yaml file:

cat <<EOT > persistent-volume-claim-rabbitmq.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  finalizers:
  - kubernetes.io/pvc-protection
  labels:
    cattle.io/creator: norman
  name: rabbitmq-claim
  namespace: my-namespace
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: "manual"
  volumeName: rabbitmq-volume
EOT

Create persistent volume claim:

kubectl create -f persistent-volume-claim-rabbitmq.yaml

Create rabbitmq-values.yaml file:

cat <<EOT > rabbitmq-values.yaml
persistence:
  enabled: true
  existingClaim: rabbitmq-claim

rabbitmq:
  password: passw0rd
  username: user

volumePermissions:
  enabled: true
EOT

Install stable/rabbitmq helm chart.

helm install \
  --name my-rabbitmq \
  --namespace my-namespace \
  --values rabbitmq-values.yaml \
  stable/rabbitmq

Watch for error.

$ kubectl get pods --namespace my-namespace --watch

NAME            READY   STATUS     RESTARTS   AGE
my-rabbitmq-0   0/1     Init:0/1          0    7s
my-rabbitmq-0   0/1     PodInitializing   0   27s
my-rabbitmq-0   0/1     Running           0    2m

READY state never reaches "1/1".
Describe the results you received:

View error.

$ kubectl describe pods --namespace my-namespace my-rabbitmq-0

Name:               my-rabbitmq-0
Namespace:          my-namespace
Priority:           0
PriorityClassName:  <none>
Node:               minikube/<IP_ADDRESS>
Start Time:         Wed, 12 Jun 2019 11:04:35 -0400
Labels:             app=rabbitmq
                    chart=rabbitmq-6.0.0
                    controller-revision-hash=my-rabbitmq-5df8f57bbc
                    release=my-rabbitmq
                    statefulset.kubernetes.io/pod-name=my-rabbitmq-0
Annotations:        <none>
Status:             Running
IP:                 <IP_ADDRESS>
Controlled By:      StatefulSet/my-rabbitmq
Init Containers:
  volume-permissions:
    Container ID:  docker://f4fdb228c233429466e2c7129d29db56b68ecff9f4ef470e5e13b487bf76af45
    Image:         docker.io/bitnami/minideb:latest
    Image ID:      docker-pullable://bitnami/minideb@sha256:86262eb759137d3a4df9be476cd8f00bf7712678faf9ada8757257b277833d1e
    Port:          <none>
    Host Port:     <none>
    Command:
      /bin/chown
      -R
      1001:1001
      /opt/bitnami/rabbitmq/var/lib/rabbitmq
    State:          Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Wed, 12 Jun 2019 11:05:01 -0400
      Finished:     Wed, 12 Jun 2019 11:05:01 -0400
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /opt/bitnami/rabbitmq/var/lib/rabbitmq from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from my-rabbitmq-token-f2krk (ro)
Containers:
  rabbitmq:
    Container ID:  docker://9425370201deeffb03884228831153fee86acc858ad498dcf663fa162da3d7b3
    Image:         docker.io/bitnami/rabbitmq:3.7.15-debian-9-r18
    Image ID:      docker-pullable://bitnami/rabbitmq@sha256:bd8db9774e573c0583660ed1cfcc3c67e3be6148f7474bc805cee7ac4464c683
    Ports:         4369/TCP, 5672/TCP, 25672/TCP, 15672/TCP
    Host Ports:    0/TCP, 0/TCP, 0/TCP, 0/TCP
    Command:
      bash
      -ec
      mkdir -p /opt/bitnami/rabbitmq/.rabbitmq/
      mkdir -p /opt/bitnami/rabbitmq/etc/rabbitmq/
      #persist the erlang cookie in both places for server and cli tools
      echo $RABBITMQ_ERL_COOKIE > /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie
      cp /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie /opt/bitnami/rabbitmq/.rabbitmq/
      #change permission so only the user has access to the cookie file
      chmod 600 /opt/bitnami/rabbitmq/.rabbitmq/.erlang.cookie /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie
      #copy the mounted configuration to both places
      cp  /opt/bitnami/rabbitmq/conf/* /opt/bitnami/rabbitmq/etc/rabbitmq
      # Apply resources limits
      ulimit -n "${RABBITMQ_ULIMIT_NOFILES}"
      #replace the default password that is generated
      sed -i "s/CHANGEME/$RABBITMQ_PASSWORD/g" /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.conf
      #api check for probes
      cat > /opt/bitnami/rabbitmq/sbin/rabbitmq-api-check <<EOF
      #!/bin/sh
      set -e
      URL=\$1
      EXPECTED=\$2
      ACTUAL=\$(curl --silent --show-error --fail "\${URL}")
      echo "\${ACTUAL}"
      test "\${EXPECTED}" = "\${ACTUAL}"
      EOF
      chmod a+x /opt/bitnami/rabbitmq/sbin/rabbitmq-api-check
      exec rabbitmq-server

    State:          Running
      Started:      Wed, 12 Jun 2019 11:06:35 -0400
    Ready:          False
    Restart Count:  0
    Liveness:       exec [sh -c rabbitmq-api-check "http://user:$RABBITMQ_PASSWORD@<IP_ADDRESS>:15672/api/healthchecks/node" '{"status":"ok"}'] delay=120s timeout=20s period=30s #success=1 #failure=6
    Readiness:      exec [sh -c rabbitmq-api-check "http://user:$RABBITMQ_PASSWORD@<IP_ADDRESS>:15672/api/healthchecks/node" '{"status":"ok"}'] delay=10s timeout=20s period=30s #success=1 #failure=3
    Environment:
      BITNAMI_DEBUG:                        false
      MY_POD_IP:                             (v1:status.podIP)
      MY_POD_NAME:                          my-rabbitmq-0 (v1:metadata.name)
      MY_POD_NAMESPACE:                     my-namespace (v1:metadata.namespace)
      K8S_SERVICE_NAME:                     my-rabbitmq-headless
      K8S_ADDRESS_TYPE:                     hostname
      RABBITMQ_NODENAME:                    rabbit@$(MY_POD_NAME).$(K8S_SERVICE_NAME).$(MY_POD_NAMESPACE).svc.cluster.local
      K8S_HOSTNAME_SUFFIX:                  .$(K8S_SERVICE_NAME).$(MY_POD_NAMESPACE).svc.cluster.local
      RABBITMQ_LOGS:                        -
      RABBITMQ_ULIMIT_NOFILES:              65536
      RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS:  +S 2:1
      RABBITMQ_USE_LONGNAME:                true
      RABBITMQ_ERL_COOKIE:                  <set to the key 'rabbitmq-erlang-cookie' in secret 'my-rabbitmq'>  Optional: false
      RABBITMQ_PASSWORD:                    <set to the key 'rabbitmq-password' in secret 'my-rabbitmq'>       Optional: false
    Mounts:
      /opt/bitnami/rabbitmq/conf from config-volume (rw)
      /opt/bitnami/rabbitmq/var/lib/rabbitmq from data (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from my-rabbitmq-token-f2krk (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             False
  ContainersReady   False
  PodScheduled      True
Volumes:
  config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      my-rabbitmq-config
    Optional:  false
  data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  rabbitmq-claim
    ReadOnly:   false
  my-rabbitmq-token-f2krk:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  my-rabbitmq-token-f2krk
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  4m41s              default-scheduler  Successfully assigned my-namespace/my-rabbitmq-0 to minikube
  Normal   Pulling    4m39s              kubelet, minikube  Pulling image "docker.io/bitnami/minideb:latest"
  Normal   Pulled     4m15s              kubelet, minikube  Successfully pulled image "docker.io/bitnami/minideb:latest"
  Normal   Created    4m15s              kubelet, minikube  Created container volume-permissions
  Normal   Started    4m15s              kubelet, minikube  Started container volume-permissions
  Normal   Pulling    4m14s              kubelet, minikube  Pulling image "docker.io/bitnami/rabbitmq:3.7.15-debian-9-r18"
  Normal   Pulled     2m42s              kubelet, minikube  Successfully pulled image "docker.io/bitnami/rabbitmq:3.7.15-debian-9-r18"
  Normal   Created    2m41s              kubelet, minikube  Created container rabbitmq
  Normal   Started    2m41s              kubelet, minikube  Started container rabbitmq
  Warning  Unhealthy  12s                kubelet, minikube  Liveness probe failed: {"status":"failed","reason":"resource alarm(s) in effect:[disk]"}
  Warning  Unhealthy  6s (x5 over 2m6s)  kubelet, minikube  Readiness probe failed: {"status":"failed","reason":"resource alarm(s) in effect:[disk]"}

Describe the results you expected:
A chart that comes up.  :-)
Additional information you deem important (e.g. issue happens only occasionally):
When running without PV/PVC, the chart comes up properly.
Version of Helm and Kubernetes:

Output of helm version:

$ helm version
Client: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.13.1", GitCommit:"618447cbf203d147601b4b9bd7f8c37a5d39fbb4", GitTreeState:"clean"}

Output of kubectl version:

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:45:25Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}

Output of minikube:

$ minikube version
minikube version: v1.0.0

Cleanup
helm delete --purge my-rabbitmq
kubectl delete -f persistent-volume-claim-rabbitmq.yaml
kubectl delete -f persistent-volume-rabbitmq.yaml
kubectl delete -f namespace.yaml

minikube stop
minikube delete

Log:
$ kubectl logs --namespace my-namespace my-rabbitmq-0

  ##  ##
  ##  ##      RabbitMQ 3.7.15. Copyright (C) 2007-2019 Pivotal Software, Inc.
  ##########  Licensed under the MPL.  See https://www.rabbitmq.com/
  ######  ##
  ##########  Logs: <stdout>

              Starting broker...
2019-06-12 15:40:26.000 [info] <0.226.0>
 Starting RabbitMQ 3.7.15 on Erlang 22.0
 Copyright (C) 2007-2019 Pivotal Software, Inc.
 Licensed under the MPL.  See https://www.rabbitmq.com/
2019-06-12 15:40:26.012 [info] <0.226.0>
 node<EMAIL_ADDRESS> home dir       : /opt/bitnami/rabbitmq/.rabbitmq
 config file(s) : /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.conf
 cookie hash    : tt8gTT+g7Hkm87a2Rcg39Q==
 log(s)         : <stdout>
 database dir<EMAIL_ADDRESS>2019-06-12 15:40:29.131 [info] <0.226.0> Running boot step pre_boot defined by app rabbit
2019-06-12 15:40:29.131 [info] <0.226.0> Running boot step rabbit_core_metrics defined by app rabbit
2019-06-12 15:40:29.131 [info] <0.226.0> Running boot step rabbit_alarm defined by app rabbit
2019-06-12 15:40:29.137 [info] <0.234.0> Memory high watermark set to 3039 MiB<PHONE_NUMBER> bytes) of 7599 MiB<PHONE_NUMBER> bytes) total
2019-06-12 15:40:29.144 [info] <0.236.0> Enabling free disk space monitoring
2019-06-12 15:40:29.144 [info] <0.236.0> Disk free limit set to 50MB
2019-06-12 15:40:29.149 [info] <0.236.0> Free disk space is insufficient. Free bytes: 0. Limit: 50000000
2019-06-12 15:40:29.150 [warning] <0.232.0> disk resource limit alarm set on node<EMAIL_ADDRESS>
   Please use the new map syntax that allows specifying socket options separately from other options.
2019-06-12 15:40:29.469 [info] <0.507.0> started TCP listener on [::]:5672
2019-06-12 15:40:29.470 [info] <0.226.0> Running boot step direct_client defined by app rabbit
2019-06-12 15:40:29.476 [info] <0.559.0> Peer discovery: enabling node cleanup (will only log warnings). Check interval: 10 seconds.
2019-06-12 15:40:29.518 [info] <0.563.0> Management plugin: HTTP (non-TLS) listener started on port 15672
2019-06-12 15:40:29.518 [info] <0.669.0> Statistics database started.
2019-06-12 15:40:29.959 [info] <0.8.0> Server startup complete; 5 plugins started.
 * rabbitmq_management
 * rabbitmq_peer_discovery_k8s
 * rabbitmq_peer_discovery_common
 * rabbitmq_web_dispatch
 * rabbitmq_management_agent
 completed with 5 plugins.

I see this line in the log:
2019-06-12 15:40:29.149 [info] <0.236.0> Free disk space is insufficient. Free bytes: 0. Limit: 50000000

I don't understand.  I have the PV at storage: 10Gi

In another test, we tried the stable/rabbitmq chart on the IBM Cloud Pak for Data kubernetes system and the chart deployed, but no pods came up.
We did a
kubectl get pods --namespace zen --watch

Didn't see the anything for the pod (i.e. not CreatingContainer, Init:0/1, PodInitializing, nor Running).

Just to make sure I'm not missing something, I just performed
helm repo update

But it did not solve the issue.

Hi @docktermj!
Thanks for all the detailed instructions! I was able to reproduce the issue in Minikube.
Can I ask why do you create the PV and PVC manually? I tried deploying the chart with the default configuration and it worked fine. So I suspect the problem is using a hostPath volume.
Regarding the issue in IBM Cloud park, could you run the following command to see why the stateful set is not creating the pods?
kubectl describe sts STATEFULSET-NAME

Hi @tompizmor!
On the question of PV and PVC...    I'm creating a series of "reference implementations" at https://github.com/Senzing/kubernetes-demo to help users understand how to bring up a docker formation using minikube.   The best teaching mechanism I know of so far is to manually create PV/PVC.   Do you have a suggestion for improvement?
I, too, was able to get the default to work, but I didn't that think it was sufficient for a "teaching exercise".
I ran into a similar issue in https://github.com/helm/charts/issues/14390 and it has been fixed thanks to @juan131.

@rgahockey   As described 2 posts up,  can you run the following command:
kubectl describe sts --namespace zen senzing-rabbitmq

...at least I think that's the STATEFULSET-NAME @tompizmor is asking for.
@tokmpizmor,  As background for you,  the instructions we are crafting are at
https://github.com/Senzing/ibm-icp4d-guide/blob/master/docs/helm-rabbitmq-db2/README.md

[root@rga-icp4d01-icpmaster-0 ~]# kubectl describe sts --namespace zen senzing-rabbitmq
Name:               senzing-rabbitmq
Namespace:          zen
CreationTimestamp:  Wed, 12 Jun 2019 09:35:32 -0500
Selector:           app=rabbitmq,release=senzing-rabbitmq
Labels:             app=rabbitmq
chart=rabbitmq-6.0.2
heritage=Tiller
release=senzing-rabbitmq
Annotations:
Replicas:           1 desired | 0 total
Update Strategy:    RollingUpdate
Pods Status:        0 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
Labels:           app=rabbitmq
chart=rabbitmq-6.0.2
release=senzing-rabbitmq
Service Account:  senzing-rabbitmq
Init Containers:
volume-permissions:
Image:      docker.io/bitnami/minideb:latest
Port:
Host Port:
Command:
/bin/chown
-R
1001:1001
/opt/bitnami/rabbitmq/var/lib/rabbitmq
Environment:
Mounts:
/opt/bitnami/rabbitmq/var/lib/rabbitmq from data (rw)
Containers:
rabbitmq:
Image:       docker.io/bitnami/rabbitmq:3.7.15-debian-9-r25
Ports:       4369/TCP, 5672/TCP, 25672/TCP, 15672/TCP
Host Ports:  0/TCP, 0/TCP, 0/TCP, 0/TCP
Command:
bash
-ec
mkdir -p /opt/bitnami/rabbitmq/.rabbitmq/
mkdir -p /opt/bitnami/rabbitmq/etc/rabbitmq/
#persist the erlang cookie in both places for server and cli tools
echo $RABBITMQ_ERL_COOKIE > /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie
cp /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie /opt/bitnami/rabbitmq/.rabbitmq/
#change permission so only the user has access to the cookie file
chmod 600 /opt/bitnami/rabbitmq/.rabbitmq/.erlang.cookie /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie
#copy the mounted configuration to both places
cp  /opt/bitnami/rabbitmq/conf/* /opt/bitnami/rabbitmq/etc/rabbitmq
# Apply resources limits
ulimit -n "${RABBITMQ_ULIMIT_NOFILES}"
#replace the default password that is generated
sed -i "s/CHANGEME/$RABBITMQ_PASSWORD/g" /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.conf
#api check for probes
cat > /opt/bitnami/rabbitmq/sbin/rabbitmq-api-check <<EOF
#!/bin/sh
set -e
URL=$1
EXPECTED=$2
ACTUAL=$(curl --silent --show-error --fail "${URL}")
echo "${ACTUAL}"
test "${EXPECTED}" = "${ACTUAL}"
EOF
chmod a+x /opt/bitnami/rabbitmq/sbin/rabbitmq-api-check
exec rabbitmq-server
Environment:
  BITNAMI_DEBUG:                        false
  MY_POD_IP:                             (v1:status.podIP)
  MY_POD_NAME:                           (v1:metadata.name)
  MY_POD_NAMESPACE:                      (v1:metadata.namespace)
  K8S_SERVICE_NAME:                     senzing-rabbitmq-headless
  K8S_ADDRESS_TYPE:                     hostname
  RABBITMQ_NODENAME:                    rabbit@$(MY_POD_NAME).$(K8S_SERVICE_NAME).$(MY_POD_NAMESPACE).svc.cluster.local
  K8S_HOSTNAME_SUFFIX:                  .$(K8S_SERVICE_NAME).$(MY_POD_NAMESPACE).svc.cluster.local
  RABBITMQ_LOGS:                        -
  RABBITMQ_ULIMIT_NOFILES:              65536
  RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS:  +S 2:1
  RABBITMQ_USE_LONGNAME:                true
  RABBITMQ_ERL_COOKIE:                  <set to the key 'rabbitmq-erlang-cookie' in secret 'senzing-rabbitmq'>  Optional: false
  RABBITMQ_PASSWORD:                    <set to the key 'rabbitmq-password' in secret 'senzing-rabbitmq'>       Optional: false
Mounts:
  /opt/bitnami/rabbitmq/conf from config-volume (rw)
  /opt/bitnami/rabbitmq/var/lib/rabbitmq from data (rw)

Volumes:
config-volume:
Type:      ConfigMap (a volume populated by a ConfigMap)
Name:      senzing-rabbitmq-config
Optional:  false
data:
Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName:  user-home-pvc
ReadOnly:   false
Volume Claims:
Events:
Type     Reason        Age                       From                    Message

Warning  FailedCreate  3m29s (x18059 over 6d2h)  statefulset-controller  create Pod senzing-rabbitmq-0 in StatefulSet senzing-rabbitmq failed error: pods "senzing-rabbitmq-0" is forbidden: unable to validate against any pod security policy: [spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden]

Formatted:
[root@rga-icp4d01-icpmaster-0 ~]# kubectl describe sts --namespace zen senzing-rabbitmq
Name:               senzing-rabbitmq
Namespace:          zen
CreationTimestamp:  Wed, 12 Jun 2019 09:35:32 -0500
Selector:           app=rabbitmq,release=senzing-rabbitmq
Labels:             app=rabbitmq
                    chart=rabbitmq-6.0.2
                    heritage=Tiller
                    release=senzing-rabbitmq
Annotations:        <none>
Replicas:           1 desired | 0 total
Update Strategy:    RollingUpdate
Pods Status:        0 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:           app=rabbitmq
                    chart=rabbitmq-6.0.2
                    release=senzing-rabbitmq
  Service Account:  senzing-rabbitmq
  Init Containers:
   volume-permissions:
    Image:      docker.io/bitnami/minideb:latest
    Port:       <none>
    Host Port:  <none>
    Command:
      /bin/chown
      -R
      1001:1001
      /opt/bitnami/rabbitmq/var/lib/rabbitmq
    Environment:  <none>
    Mounts:
      /opt/bitnami/rabbitmq/var/lib/rabbitmq from data (rw)
  Containers:
   rabbitmq:
    Image:       docker.io/bitnami/rabbitmq:3.7.15-debian-9-r25
    Ports:       4369/TCP, 5672/TCP, 25672/TCP, 15672/TCP
    Host Ports:  0/TCP, 0/TCP, 0/TCP, 0/TCP
    Command:
      bash
      -ec
      mkdir -p /opt/bitnami/rabbitmq/.rabbitmq/
      mkdir -p /opt/bitnami/rabbitmq/etc/rabbitmq/
      #persist the erlang cookie in both places for server and cli tools
      echo $RABBITMQ_ERL_COOKIE > /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie
      cp /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie /opt/bitnami/rabbitmq/.rabbitmq/
      #change permission so only the user has access to the cookie file
      chmod 600 /opt/bitnami/rabbitmq/.rabbitmq/.erlang.cookie /opt/bitnami/rabbitmq/var/lib/rabbitmq/.erlang.cookie
      #copy the mounted configuration to both places
      cp  /opt/bitnami/rabbitmq/conf/* /opt/bitnami/rabbitmq/etc/rabbitmq
      # Apply resources limits
      ulimit -n "${RABBITMQ_ULIMIT_NOFILES}"
      #replace the default password that is generated
      sed -i "s/CHANGEME/$RABBITMQ_PASSWORD/g" /opt/bitnami/rabbitmq/etc/rabbitmq/rabbitmq.conf
      #api check for probes
      cat > /opt/bitnami/rabbitmq/sbin/rabbitmq-api-check <<EOF
      #!/bin/sh
      set -e
      URL=\$1
      EXPECTED=\$2
      ACTUAL=\$(curl --silent --show-error --fail "\${URL}")
      echo "\${ACTUAL}"
      test "\${EXPECTED}" = "\${ACTUAL}"
      EOF
      chmod a+x /opt/bitnami/rabbitmq/sbin/rabbitmq-api-check
      exec rabbitmq-server
    Environment:
      BITNAMI_DEBUG:                        false
      MY_POD_IP:                             (v1:status.podIP)
      MY_POD_NAME:                           (v1:metadata.name)
      MY_POD_NAMESPACE:                      (v1:metadata.namespace)
      K8S_SERVICE_NAME:                     senzing-rabbitmq-headless
      K8S_ADDRESS_TYPE:                     hostname
      RABBITMQ_NODENAME:                    rabbit@$(MY_POD_NAME).$(K8S_SERVICE_NAME).$(MY_POD_NAMESPACE).svc.cluster.local
      K8S_HOSTNAME_SUFFIX:                  .$(K8S_SERVICE_NAME).$(MY_POD_NAMESPACE).svc.cluster.local
      RABBITMQ_LOGS:                        -
      RABBITMQ_ULIMIT_NOFILES:              65536
      RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS:  +S 2:1
      RABBITMQ_USE_LONGNAME:                true
      RABBITMQ_ERL_COOKIE:                  <set to the key 'rabbitmq-erlang-cookie' in secret 'senzing-rabbitmq'>  Optional: false
      RABBITMQ_PASSWORD:                    <set to the key 'rabbitmq-password' in secret 'senzing-rabbitmq'>       Optional: false
    Mounts:
      /opt/bitnami/rabbitmq/conf from config-volume (rw)
      /opt/bitnami/rabbitmq/var/lib/rabbitmq from data (rw)
  Volumes:
   config-volume:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      senzing-rabbitmq-config
    Optional:  false
   data:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  user-home-pvc
    ReadOnly:   false
Volume Claims:  <none>
Events:
  Type     Reason        Age                       From                    Message
  ----     ------        ----                      ----                    -------
  Warning  FailedCreate  3m29s (x18059 over 6d2h)  statefulset-controller  create Pod senzing-rabbitmq-0 in StatefulSet senzing-rabbitmq failed error: pods "senzing-rabbitmq-0" is forbidden: unable to validate against any pod security policy: [spec.initContainers[0].securityContext.runAsUser: Invalid value: 0: running with the root UID is forbidden]

So for IBM Cloud Pak, I think this is the story:
The RabbitMQ chart needs to change ownership of the files in the "persistence path".
It does that with an initContainer in statefulset.yaml.
However the security policies in IBM Cloud Pak seem to prevent that from happening.
So @rgahockey, you and I can continue down that path (which isn't really part of this GitHub issue.)

@tompizmor, is there anything else we can do or provide to help get the original issue resolved?

WAS THIS EVER IMPLEMENTED??? It appears back in Dec 19, 2018 there was supposed to be a way to set the SecurityContext ...
Hi @obeyler @desaintmartin
The initContainer was added to avoid issues on some K8s distributions were SecurityContext wasn't respected. Therefore, we needed a way to ensure the volumes had the proper permissions.
What do you think about adding a parameter such as initContainer.enabled that can be set to true/false so you can decide whether to install the chart with it or not? cc/ @tompizmor
@tompizmor
Collaborator
tompizmor commented on Dec 19, 2018
Agree. We should have enough flexibility to enable/disable both the securityContext and the initContainer.

@rgahockey  I think that it's mandatory to have a way to disable the initContainer as if you run it in a secured K8S with PodSecurityPolicy runAsNonRoot the initContainer with root role won't be a accepted.
So I agree that it's a good idea to add initContainer.enabled
I'm less sure for the need of such tag to enable or not SecurityContext. At the end, SecurityContext  is  always present in yaml file (even as empty object).

Good conversation.  Can it be moved to a new issue?
This issue is for Liveness and Readiness probes on minikube?

👍

Isn't this already the case?
.Values.volumePermissions.enabled allows to define (or not define) the initContainer.

@docktermj

The best teaching mechanism I know of so far is to manually create PV/PVC. Do you have a suggestion for improvement?

For me is weird having to create the PV manually as you would usually have a storage provider that will that automatically for you.
The original issue was that liveness and readiness probes fail when you use an already existing hostPath volume. In that case, you can see the following error:
2019-06-12 15:40:29.149 [info] <0.236.0> Free disk space is insufficient. Free bytes: 0. Limit: 50000000

My take on this is that RabbitMQ is not able to measure the available space when you mount a hostPath volume. However, right now I have no idea how to debug this.

@tompizmor   I agree that a storage provider would set up the PV,  but in my case  I'm educating folks using minikube,  so I need to demonstrate the PV/PVC concept.
Yikes!   Are we dead in the water?  You mentioned that you could recreate.   Is there anything I can do to move the ball forward?

Hi @docktermj ,
Why not use a single Pod mounting volumes to demonstrate the PV/PVC concept?
Don't you think using a Chart is a weird way to show that concept?
The majority of Helm Charts are prepared to use dynamic provisioning, did you try with other Chart to know if it only happens for RabbitMQ or is a general issue?

Hi @tompizmor!
Is there any plan to fix this issue on minikube?
In the meantime, I'm using:
livenessProbe:
  enabled: false

readinessProbe:
  enabled: false

Which is probably not an illustration of "best practice".

Any update on
livenessProbe:
  enabled: true

readinessProbe:
  enabled: true

issues on Qinikube

If this issue is not fixed, please reopen.

Hi @tompizmor!
Why is this a stale issue?   Has it been fixed?

/reopen


F5 framework selector

Sorry, I needed to recreate the branch which closed the original PR https://github.com/dotnet/roslyn-project-system/pull/1585.
This should just contain the changes to address the code review feedback.
PR for post dev15 RTW.
Implemented the design that was available in Dev14:
Added a new menu item to the debug dropdown which shows the currently active framework being used for debugging.
a. The selected framework appears in the Framework menu name so that you don’t have to expand the menu to see the active one.
b. The frameworks appear in the menu in the order they are defined in the property
c. The current active framework is remembered in the .user file so it persists across VS sessions. It defaults to the first one if there is no existing setting or the existing setting doesn’t match any the frameworks being targeted.
d. The framework names are displayed as they exist in the project file. I’d like to display something better but I didn’t have any code to convert the short name to a friendly name. We could possible resolve to the TargetFrameworkMoniker property and display that - but that requires more evaluation. Certainly something to address later.
Added an IActiveDebugFrameworkServices public interface which exposes access to the ConfiguredProject for the active debug framework.
Updated the Debugger providers and (token replacer) to resolve properties against the active debug frameworks ConfiguredProject.
Unit test coverage for the new components
Fixed a problem with ProjectExportProvider. It claims it can be called on a background thread but doing so deadlocked as it was using QueryService to get to ProjectServices. Fixed it to just import the ProjectServices MEF component.

Opened https://github.com/dotnet/roslyn-project-system/issues/1674 to track fixing the framework names in the menu

Is this available/going to be available in the preview channel for VS2017? If so, when?


"Startup breakpoints" are not caught when using launch.json config type "chrome".

First: this extension is extremely awesome!
I've been tinkering around a bit and use it with the following launch.json file to debug Emscripten WASM targets running in Chrome (together with the CMake Tools extension):
{
 "version":"0.2.0",
 "configurations":[
  {
   "type":"chrome",
   "request":"launch",
   "name":"Debug in Chrome",
   "url":"http://localhost:8080/${command:cmake.launchTargetFilename}",
   "server":{
    "program":"httpserver.js",
   }
  }
 ]
}

The httpserver.js helper script starts a node http-server like so:
const { execSync } = require('child_process');
execSync('http-server -c-1 -g .', {
  cwd: '[path with index.html]',
  stdio: 'inherit',
  stderr: 'inherit',
});

...now when pressing F5, this will start a http-server, Chrome, and a debug session in VSCode, which all in all works wonderfully.
Only problem I have is that "early breakpoints" in the C code are not caught, for instance a breakpoint at the start of main() is not detected, only breakpoints that also trigger later (for instance in the per-frame callback).
It does work in the following situations:

when using the palette command 'Debug: Open Link' instead of launch.json
or when restarting a debugging session via 'Restart' button in the VSCode debugging controls

I've been looking for something like a "wait for debugger to attach" option in the launch.json attributes, but without luck.
TBH I don't know if this can even be fixed in the DWARF extension, or whether this is a problem of the chrome launch configuration, but it's soooo close to perfect that it would be wonderful if it can be fixed somehow :)
Cheers!

Here in this movie you can see that it takes a few frames until a breakpoint in the frame callback is caught, and later I set a breakpoint in the init function which is immediately caught when restarting the debug session:
https://github.com/microsoft/vscode-dwarf-debugging-ext/assets/1699414/bf17bdf7-46bc-458a-b037-148519f17062

Fixed in on the nightly extension https://github.com/microsoft/vscode-js-debug/?tab=readme-ov-file#nightly-extension

Awesome! Thanks!

Btw, do I read this right that WASM DWARF debugging will eventually move into core VSCode (e.g. no additional extensions required?)

No, it'll always be separate. VS Code is a ~150MB download and the DWARF debugging stuff is in a big 30MB (compressed) WASM binary. We wouldn't take a 20% overall size increase for such a niche feature

Argh, hmm ok, it works "sometimes" but I also quite often get an error looking like this instead (in a new vscode tab with a title like VM46947589:
Could not load source 'chromewebdata/(index)꞉6839:9': Source not found.
When refreshing the page the debug session starts and breakpoints are hit (e.g. the same workaround as before).
Is this a bug in the vscode-dwarf-debugging extension or should I report that vscode-js-debug repo?


Support for Test Devices

Is it possiblbe to have support for Test devices?
Currently I am getting error code of 3 when trying to display my ads, which means that I dont have ads to be displayed. So I want to use some test ads. For the same, I want my device to be a test device.

Thanks for details. When I use the firebase admob plugin I am able to see
actual ads but not with us.
Thanks,
Purusothaman Ramanujam
On Thu, Dec 20, 2018, 9:00 AM apitutinteractive<EMAIL_ADDRESS>wrote:

if this still happening
"which means that I dont have ads to be displayed"
wait for a few hour
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/YoussefKababe/admob_flutter/issues/4#issuecomment-448848153,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABBx55TsHwYmfNhloqC7j8rRDA51f6lcks5u6wQ6gaJpZM4Zay_v
.

I feel that there is a subtle difference between using test unit IDs and adding your device as a test device.
With test units - you see the simple test ad. You also need to refactor your code before release. :)
With test devices - you see actual ads from your unit, but they're in "test mode"
You should see a message that says
Use AdRequest.Builder.addTestDevice("<removed>") to get test ads on this device.

@gcshri I know the difference between the two, I just still didn't have the opportunity to implement remaining stuff. About refactoring, did you actually check the code? Found any weird/messy parts? Let me know so I can take them in consideration!

I understand this isn't being actively maintained but did anyone work out a way to adapt this to use AdRequest.Builder.addTestDevice?


Enhancement: Enable phpdoc_separation fixer

This PR

[x] enables the phpdoc_separation fixer
[x] runs make cs

💁♂ For reference, see https://github.com/FriendsOfPHP/PHP-CS-Fixer/tree/v2.8.0#usage:

phpdoc_separation [@Symfony]
Annotations in phpdocs should be grouped together so that annotations of the same type immediately follow each other, and annotations of a different type are separated by a single blank line.

Thank you, @chartjes!


Speed up tests by running pytest in parallel

Let's use pytest-xdist and run tests in parallel on github-actions

Note that with GitHub actions, you'll only get 2 cores, so the speedup is limited (but still worth it IMO).
Also, pytest-xdist suppresses test output - the -s option has no effect.

Not needed as we moved to Protostar.


Error:SamAutomaticMaskGenerator function has a large memory footprint

GPU：4090 24G
System：Ubuntu for WSL2
Model：sam_vit_h
Image_size：[1024,1024]
Parameter settings：
model=sam,
points_per_side=128,
points_per_batch = 64,
pred_iou_thresh=0.86,
stability_score_thresh=0.92,
crop_n_layers=3,
crop_n_points_downscale_factor=2,
min_mask_region_area=100,
process_batch_size=4
Issue：
When I use SamAutomaticMaskGenerator，GPU memory usage up to 55GB.

And there will be an error.
[torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 16.63 GiB. GPU 0 has a total capacity of 23.99 GiB of which 0 bytes is free. Including non-PyTorch memory, this process has<PHONE_NUMBER>4.00 GiB memory in use. Of the allocated memory 34.86 GiB is allocated by PyTorch, and 5.63 GiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation.  See documentation for Memory Management  (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)
]

However, when using the original SAM code, this problem does not exist, and the GPU memory will not exceed 24GB.

@lstswb have u solved this?

@lstswb have u solved this?

no

@lstswb have u solved this?

Not yet

Does the code snippet from the example help?
In particular
https://github.com/pytorch-labs/segment-anything-fast/blob/387488bc4c7ab2ae311fb0632b34cab5cbfbab78/amg_example/amg_example.py#L36-L44
note that you can adjust process_batch_size for a smaller memory footprint.

Does the code snippet from the example help?
In particular
https://github.com/pytorch-labs/segment-anything-fast/blob/387488bc4c7ab2ae311fb0632b34cab5cbfbab78/amg_example/amg_example.py#L36-L44
note that you can adjust process_batch_size for a smaller memory footprint and note the use of sam_model_fast_registry

I tried to adjust batch_size, and the GPU memory footprint was reduced, but it still far exceeded the original code.

Yes, the batch is larger, but should be faster. The original code uses batch size 1. You can try setting it to batch size 1.

Yes, the batch is larger, but should be faster. The original code uses batch size 1. You can try setting it to batch size 1.

I tried to adjust batch_size=1, but still got GPU memory error.

Hm, I assume you're also using the GPU for the display manager? That will take up additional memory as well. Maybe the solution in https://github.com/pytorch-labs/segment-anything-fast/issues/97 will help.
Can you use your onboard GPU (if you have one) for the display manager and the GPU for the model only? Does it work with vit_b?

Hm, I assume you're also using the GPU for the display manager? That will take up additional memory as well. Maybe the solution in #97 will help.
Can you use your onboard GPU (if you have one) for the display manager and the GPU for the model only? Does it work with vit_b?

Vit_b can be used normally. Display takes up only a small portion of GPU memory. Setting vit_h equally works fine with the original code.

Hm, can you try setting the environment variable SEGMENT_ANYTHING_FAST_USE_FLASH_4 to 0?

Hm, can you try setting the environment variable SEGMENT_ANYTHING_FAST_USE_FLASH_4 to 0?
SEGMENT_ANYTHING_FAST_USE_FLASH_4 has been set to 0. But the problem remains.

Hm, I'm not sure to be honest. It seems to work on other 4090s, but I think they're on Linux and not Windows.

Hm, I'm not sure to be honest. It seems to work on other 4090s, but I think they're on Linux and not Windows.

Well. I try to do this using a linux system instead of using ubuntu based on WSL2


XFail tests until final fix can be put in

This is here to mark some tests as xfail until #953 can be addressed

not going to do a build until we get the precommit build passing again.

build

The CI failed again with this:
10:50:01  GpuDeviceManagerSuite:
10:50:02  - RMM pool limit *** FAILED ***
10:50:02    java.lang.UnsupportedOperationException: Not allowed to modify active Spark session.
10:50:02    at org.apache.spark.sql.SparkSession$.clearActiveSession(SparkSession.scala:1011)
10:50:02    at com.nvidia.spark.rapids.TestUtils$.withGpuSparkSession(TestUtils.scala:137)
10:50:02    at com.nvidia.spark.rapids.GpuDeviceManagerSuite.$anonfun$new$1(GpuDeviceManagerSuite.scala:40)
10:50:02    at org.scalatest.OutcomeOf.outcomeOf(OutcomeOf.scala:85)

I think this needs to merge up to the latest on branch-0.3 to get the fix.

build


Application with a dark theme on start is flickering from white to black

Describe the bug
Any WPF UI application with a dark theme is flickering on start from white to black. First, the white screen appears, following screen changes from white to black.
To Reproduce
Run WPF UI Simple Demo
Expected behavior
Application should start with a black screen by default with a dark theme. Flickering from white to black with a dark theme is not very convinient.
Screenshots
https://user-images.githubusercontent.com/97022983/189654083-b99bbf01-2dbd-4543-9de5-e3e4c0873e02.mp4
Desktop (please complete the following information):

OS: Windows 10
.NET: net6.0-windows
Version: 2.0.2

This seems to be because SimpleDemo uses Window instead of ui:UiWindow. Can you try using ui:UiWindow in your app?

I've just modified SimpleDemo to use ui:UiWindow, but the result is the same.

Alright, I gave the code a lookover instead of going off of memory. The issue should be fixed by pull request #389, so feel free to cherry pick the changes from there for the time being.

Alright, I gave the code a lookover instead of going off of memory. The issue should be fixed by pull request #389, so feel free to cherry pick the changes from there for the time being.

Thanks for the patch. But on my machine, the problem with the initial white background remains. May be it is some WPF specific to initially run the window with white background...

It is possible that the issue is Windows 10 specific, as I do most of my development work on Windows 11. I know the flash is caused by the WindowBackdropType not being set, so it's odd it's occurring even with that patch.
https://user-images.githubusercontent.com/7614507/189692457-b5dd3b66-53a5-409d-86ed-17802211019d.mp4

@FreeTheTech101 thanks for the help! I will try find how to fix it on my Windows 10 platform.

Finally, it is a clear WPF issue (not WPF UI). And I found a workaround on my Windows 10. We need to use the following Window attributes
<ui:UiWindow
    ...
    WindowStyle="None"
    AllowsTransparency="True"
>


Provide WebSocket ready state constants to follow the Web IDL definition

See https://github.com/cloudflare/workerd/issues/1370. I also added in a little macro so that we could reuse the existing constants for both new and old js constants.

https://github.com/cloudflare/workerd/compare/02323e2ed2988338cc011465c09854d69f002177..d96d6447c5a918a5b0addb07df0de219a5e30669 rebases on master


Emmet abbreviation breaks after paste

VSCode Version: 1.28.2
OS Version: macOS 10.13.6

Steps to Reproduce:

Begin typing an Emmet abbreviation
Append to an abbreviation using the paste commend (e.g. div. + paste foo = div.foo)

At this point, VSCode no longer sees div.foo as an Emmet abbreviation (no tab completion available). Emmet functionality can be restored by adding any character, but this feels unnecessary. Ideally, Emmet would continue to recognize an abbreviation after using the paste command to append to a string.

Does this issue occur when all extensions are disabled?: Yes

Emmet has been implemented using the auto-completion feature.
Auto-completion is triggered when typing and not pasting.
To get around this you can manually trigger the auto-completion feature by pressing Ctrl+Space after pasting the text. Or if you want to always have the tab key trigger emmet, then set emmet.triggerExpansionOnTab to true

Sounds good. Thanks, @ramya-rao-a!


Use Hashing

This improves how we detect and resolve file changes when ggt sync starts.
I've split this PR into 2 commits. I recommend reading them individually so the changes are easier to follow.

Delete old sync implementation
Add new sync implementation

Before this PR
To detect local changes, we compared the largest mtime on the local filesystem to the largest mtime we saw when ggt sync stopped. If the largest mtime on the local filesystem was greater than the largest mtime we last saw, we assumed local files had changed.
To detect gadget (remote) changes, we compared the latest files version to the last files version we saw when ggt sync stopped. If the latest files version was greater than our local files version, we assumed gadget (remote) files had changed.
If local changes were detected, we prompted the user to either reset/undo all their local changes or keep their local changes and merge them with any gadget (remote) changes.
After this PR
First, we fetch the hashes of the files version we last saw when ggt sync stopped.
To detect local changes, we compare the files version hashes to the hashes on the local filesystem. If the hashes are different, we know local files have changed.
To detect gadget changes, we do the same thing and compare the files version hashes to the hashes of the latest files version. If the hashes are different, we know gadget files have changed.
If both the local filesystem and gadget changed the same file in conflicting ways, i.e.:

both updated the same file with different content
one deleted the file while the other updated it

Then we prompt the user to either keep their local conflicting changes or keep gadgets conflicting changes. All non-conflicting changes are always merged.

This looks good to me.
Do we want to do any more in house testing before this becomes the default?

I feel confident enough to merge this into main, but I won't ship this until I've done another round of testing. I'll ship another experimental version and test that one while I wait for docs to finish.


Add default_ipv4 to required_facts to gather ansible_hostname

Enhancement: Add default_ipv4 to required_facts to gather ansible_hostname fact
Reason: The role didn't gather ansible_hostname but used it in tasks/main.yml
Result: The bug is fixed

[citest]


feat: updated content & styles on homepage, footer

Issue

Closes #1060
Closes #1111

Description
This PR updates the Detroit homepage and global site footer. It also breaks up the large single overrides CSS file into several files in a more logical and maintainable way (with more improvements to follow hopefully once we add 2nd-gen theming support to ui-components).
How Can This Be Tested/Reviewed?
You can preview the update homepage here and compare with the Figma examples in #1060:
https://deploy-preview-1134--detroit-public-dev.netlify.app/
Checklist:

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have reviewed the changes in a desktop view
[x] I have reviewed the changes in a mobile view
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] Any dependent changes have been merged and published in downstream modules
[ ] I have assigned reviewers
[ ] I have run yarn generate:client and/or created a migration if I made backend changes that require them
[ ] I have exported any new pieces added to ui-components
[ ] My commit message(s) is/are polished, and any breaking changes are indicated in the message and are well-described
[ ] Commits made across packages purposefully have the same commit message/version change, else are separated into different commits

Reviewer Notes:
Steps to review a PR:

Read and understand the issue
Review the code itself from a style point of view
Pull the changes down locally and test that the acceptance criteria is met
Also review the acceptance criteria on the Netlify deploy preview (noting that these do not yet include any backend changes made in the PR)
Either explicitly ask a clarifying question, request changes, or approve the PR if there are small remaining changes but the PR is otherwise good to go

On Merge:
If you have one commit and message, squash. If you need each message to be applied, rebase and merge.

@slowbot The design linked in these issues contradicts some of the design updates we have made recently. I know we recently touched based on what the listing cards should look like on the homepage from this Figma - which is correct?

touched base offline with @slowbot, we will be adding back this latest listings scroll piece, so we'd like to just comment it out and not remove it so that it's easy to add back in later

Thanks @YazeedLoonat for noticing those discrepancies, I'll work on fixes.
@slowbot couple of questions for you:

the very top bar (for language selection) I think is the wrong color

Is that right? Do we need to update the CSS for that?
And do we need to swap out a new background image for the hero? If so, can you attach a new one here? Thanks.

touched base offline with @slowbot, we will be adding back this latest listings scroll piece in the relatively near future, so we'd like to just comment it out and not remove it so that it's easy to add back in later

@emilyjablonski Yeah it's still in there, just "switched off" in a feature flag-y way. Easy to switch back on later.

OK, I think all feedback's now been addressed, pending those two questions for @slowbot. One other thing I noticed: we should use the newer envelope & doorway icons for the new CTAs, but we'd need another sync from Bloom core dev in order to do that.

@YazeedLoonat and @slowbot , you both requested changes, can you please review and approve if it looks good. @slowbot , there is also a question for you from @jaredcwhite above.

Leaving a note here for followup as well (after a convo with Jesse) that we're hoping to get a better resolution version of the image. But I'll add what we got for now in order to merge.


Do not drop snapshots during publishLatest()

As of now, publishLatest() function deletes if there are any previous snapshots and creates new snapshots.
It should work as follows :
If the snapshot already exists, create new snapshot with a counter appended at the end. Eg : snapshot-testing-20180910-1

@anupam-git, is this still an issue?

I dont think its still an issues since you've rewritten the script and reconfigured aptly.


Windows version now available

https://github.com/pguerin3/halmak4windows

ohey, do you mind making a PR for that please? thanks!

Check this out:
https://medium.com/@paulguerin/the-search-for-the-worlds-best-keyboard-layout-98d61b33b8e1?source=friends_link&sk=288b4ecba957175484463cfc7f1b6fe6

nice write up, thanks! btw, halmak has the control underlay that keeps the ctrl, alt, win layers intact QWERTY like, so all you ZXCV, S etc keep working the usual ;)
I have it working in OSX/Linux. I have a windows version as well laying around, just thought you might have it done better than I, since im not a real good window user ;)

i can push mine in a PR if you want so you could compare notes and make it good. then i'd be happy to merge it, people had been asking for it for a while

I'm still a beginner in git, so if its easy from your end to merge then you can do that.
For the layers, my version remaps cntrl to follow Halmak, so undo/cut/copy/paste follows Halmak instead of Qwerty.
The alt and other layers follow Qwerty.
If this isn't what you want then I can change my version.
I also created an X11 version, that has the same behaviour as my Windows version (undo/cut/copy/paste follows Halmak)
I want to add it to the official repository: https://github.com/freedesktop/xkeyboard-config
Again if this isn't what you want then I can change my version.
You can advise on the direction you want to take.

Note - xkb is for the console terminal, and different to X11.
Most users will be using X11, so I considered the console version to be lower priority.
I did create a console version of Halmak.

i have actually just published my linux configs https://github.com/MadRabbit/halmak/tree/master/linux it has the ctrl+zxcv working as QWERTY both in terminal and X11. using it right now :)
im mostly interested in the windows config at this point

I have been able to create a Halmak layout with the Qwerty cntrl keys.
The cntrl keys work like Qwerty - as expected in the gvim editor.
However when I use Chrome, Notepad, or Wordpad, the cntrl keys work like Halmak!
So this dual-personality is very unusual, and I don't have a workaround for this.
For me - I prefer the Halmak cntrl keys because I use the mouse to select, and copy, then the cntrl-v to paste.
In Halmak the v key is closer to the left cntrl - so less hand stretching - so much better than the Qwerty cntrl behaviour!

I just cracked the case!
I now have a Halmak layout with the Qwerty cntrl layout.
I'll update my repo soon.

I've updated: https://github.com/pguerin3/halmak4windows
Halmak maps to the Halmak layout for normal characters, and the Qwerty layout for control characters. This means undo (cntrl-z), cut (cntrl-x), copy (cntrl-c), and paste (cntrl-v) and the other control characters are in their original Qwerty positions on the keyboard.
HalmakX maps to the Halmak layout for both normal and control characters. This means undo (cntrl-z), cut (cntrl-x), copy (cntrl-c), and paste (cntrl-v) and the other control characters are in their new Halmak positions on the keyboard.
Tell me your thoughts so I can finalise for the pull request.

hi there, closing this as there is no further actions


2 of 3 devices work perfectly, firmware incompatibility?

I’m new to homebridge and have been blown away at how smooth the system is, your plugin included! After adding three Wi-Fi LED strips to the magichome app I installed your plugin and restarted homebridge. 2 of the 3 controllers were found and added with no issue, but I can’t get the third to connect at all. The only difference I can identify is the one not showing up is running what appears to be a newer firmware (v6 vs v4)
Here’s my configuration:
{
"pruning": {
"pruneMissingCachedAccessories": false,
"restartsBeforeMissingAccessoriesPruned": 3,
"pruneAllAccessoriesNextRestart": false
},
"whiteEffects": {
"simultaniousDevicesColorWhite": true,
"colorWhiteThreshold": 10,
"colorWhiteThresholdSimultaniousDevices": 50,
"colorOffThresholdSimultaniousDevices": 5
},
"deviceManagement": {
"blacklistOrWhitelist": "blacklist",
"blacklistedUniqueIDs": [
""
]
},
"platform": "homebridge-magichome-dynamic-platform"
}
And here are screenshots of the devices showing as connected and controllable in magichome, active on my network, but being missed in the discovery process on homebridge restart. I’ve manually reset and re-paired the problem controller several times, can’t seem to get homebridge to see it!
Is it possible to manually add in config since I know the MAC and IP?

Hi, thank you for bringing this to my attention. Thank you for showing me all of that information, it helped confirm that there are, unfortunately, no quick solutions.
I have devices with versions 3-9 with the exception of 4 and 6 so I am delighted version 4 is working properly. My plugin does not offer a "manual" device addition feature as there are already many plugins that do so. Additionally, even if the plugin had that ability, the protocol wouldn't be mapped out properly for each version to work. It's not completely out of the question but adding that sort of feature would not be a quick as I'd want it to be robust enough to work 90% of the time (or in your case at least more than 66.66% of the time :P).
I'll start with low hanging fruit. Fair warning, these are all longshots:

Have you restarted homebridge a few times? Sometimes the discovery program doesn't pick things up on the first try. Don't worry, your devices will persist cross-restart. Restart 3 or 4 more times.
Install  gordalina magic-home cli and scan with magic-home scan [--json] [--timeout 500] a few times. Does it discover your missing controller?
You've mentioned that you reconnected the light to WiFi a few times, are both your lights and the device hosting homebridge connected to the same WiFi UUID? A few notes about this. Magichome controllers cannot connect to 5GHz WiFi frequency bands, only 2.4GHz. Many routers combine these two bands as a single broadcasted ID and have devices default to 5GHz if they have that capability else falling back to 2.4GHz if they do not. Make sure your device hosting homebridge is on the 2.4 GHz band. You can ensure this by going in your router's settings and individually naming your 2.4GHz band something like "Router_Name-24". The Magichome app has some nasty tricks like coaxing the device list from your router to find controllers, a feature my plugin does not implement for privacy reasons (and laziness). So sometimes the app finds devices my plugin can't find.

If I think of any more ez-pz's I'll let you know. If these solutions don't work we'll move on to reverse engineering your v6 controller's elusive UDP broadcast protocol. Good luck.

Thank you for responding so quickly 💪
I can see why adding manual config is unnecessary complexity. I hoped that nudging the plugin in the right network direction would help, but hearing there are so many different versions with completely different control schemes I realize that was a naive suggestion.
To answer your questions:

Yes, I restarted homebridge multiple times after each factory reset of the v6 controller. Nothing I tried then made the device show in homebridge.

I installed the CLI and before messing with the network settings, the scan only returned the two v4 devices.

I use two distinct SSIDs broadcast by two APs. Each SSID is limited to either 2.4 or 5, but they are otherwise a single network using the same address space etc. The Magichome devices are all connected to the 2.4 network. My homebridge setup is running on a Mac Mini that's connected to the network via ethernet, and usually has wifi turned off.

To test, I connected the Mini to the 2.4 network (but did not remove the hard-line) and ran magic-home scan --json --timeout 500 a few times. The first time only the two v4 controllers showed up, and the second time only the v6 controller showed. On the third scan (and every scan since), only the two v4 controllers were found.
Second scan result:
USER:~ USER$ magic-home scan --json --timeout 500
[
{
"host": "<IP_ADDRESS>",
"id": "2CF432A025D1",
"model": "AK001-ZJ210"
}
]
Seeing that it was found once, I crossed my fingers and restarted homebridge. The v6 device was immediately found and added to homebridge and my home app alongside the two v4 devices.
I was able to control all three devices from inside Home, including changing colors and brightness.
Hoping that the 'connection' had been made, I turned off wifi (I would prefer that this machine is hard-lined only) and tested again, but the v6 device connection was lost.
Here are a few errors from the process:
After turning wifi off without restarting homebridge:
(node:33568) UnhandledPromiseRejectionWarning: Error: connect EHOSTDOWN <IP_ADDRESS>:5577 - Local (<IP_ADDRESS>:57280)
at internalConnect (net.js:923:16)
at defaultTriggerAsyncIdScope (internal/async_hooks.js:351:12)
at net.js:1011:9
at processTicksAndRejections (internal/process/task_queues.js:79:11)
(node:33568) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag --unhandled-rejections=strict (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
After then restarting homebridge:
[homebridge-magichome-dynamic-platform]
Warning! Continuing to register cached accessory 'LED - Back Yard' despite not being seen for 1 restarts.
Model: 'AK001-ZJ210'
Unique ID: '2CF432A025D1'
IP-Address: '<IP_ADDRESS>'
Version 6
Version Modifier: 51
Attempting to use the homebridge and Home app UIs to turn the light on even though the device was not seen:
[homebridge-magichome-dynamic-platform] getState() error:  Error: connect EHOSTDOWN <IP_ADDRESS>:5577 - Local (<IP_ADDRESS>:58256)
at internalConnect (net.js:923:16)
at defaultTriggerAsyncIdScope (internal/async_hooks.js:351:12)
at net.js:1011:9
at processTicksAndRejections (internal/process/task_queues.js:79:11) {
errno: 'EHOSTDOWN',
code: 'EHOSTDOWN',
syscall: 'connect',
address: '<IP_ADDRESS>',
port: 5577
}
Turning wifi back on and fully deactivating the ethernet interface did not resolve the disconnection issue, even after restarting homebridge. It seems that once the connection is lost, it's completely toast and you have to start over. I set the plugin to prune missing devices and fell back to just the two v4 controllers in homebridge.
Starting the process over, I've been unable to see the v6 device via CLI scan again - it has only ever showed once.
Here is what I've found: if I try to add the v6 controller while the lights are off, it cannot be found by homebridge. If I turn the lights on using the magichome app, the homebridge plugin sees the controller on restart and adds it successfully. Once added I have full control in homebridge and the home app.
The second time adding the v6 device it had a different default name: RGBWW Non-Simultanious, whereas the first time it showed as Simple RGB just like the two v4 devices.
So this is progress! Thank you for the wifi suggestion, I would not have thought of this since the v4 controllers worked without the homebridge server needing to be on wifi.
My question now, assuming the current connection holds, is: is it possible that I could eventually control the v6 from my wired Mac Mini with wifi turned off? Is this possibly a network issue on my end, or is this something that's baked into the control scheme?
Thanks again for your work on this plugin, I can't imagine being forced to use the awful magichome app for control.

Ah yes, the infamous EHOSTDOWN bug. That occurs due to parts of the transmit code that allows the plugin to understand TCP responses from certain rgbww controllers. The issue is most likely not with your network but your thorough troubleshooting process has given me some insight on the bug.
The reason you're getting the second error is because my plugin is auto assigning the wrong transmit protocol to it when it receives no data after the first TCP handshake. Unfortunately model number alone is not sufficient to determine a controllers type as identical model numbers (transmitted over the UDP broadcast reply) can have different capabilities and thus different transmit protocols. When you try to control the device, a 9 byte message is sent instead of an 8 byte message. Why does it fail to connect over a bridged connection for only the V6, I have no clue. Some genius probably implemented some untested code in the V6 firmware that goofed everything up.

If you want to stay with my plugin, try this:
remove all the devices with pruning
repeat your v6 discovery processes again but this time, when you turn off WiFi on your Mac, don't restart the router. Or if you absolutely have to, be sure to assign a static IP to the v6 controller. In fact, that's probably a good practice anyways. The devices are persistent and I've written logic to fix IP discrepancies, but only if they show up when scanned.

When you restarted your router, that probably changed the IP of the v6 device, but without being able to scan for it anymore my plugin was unable to resolve that IP discrepancy and sent a message to your smart toaster or something.
If that doesn't work, I still do not know how to fix bug without breaking other things. However, @tom-23 has a magichome plugin, albeit less robust but better named (hi Tom), that seems to solve that issue for all the other controllers. My suggestion is to do the following.

Remove the config for my plugin "homebridge magichome dynamic platform" and ensure the tiles no longer show up in homekit. Be sure to restart homebridge.
Install homebridge-magichome-led and add the necessary config to your config.json.
Follow your steps to get the v6 to appear.
Disconnect your WiFi.

This should tide you over until I get time to fix this bug.
Alternatively, I'd suggest investing in a Raspberry Pi 3b or 3b+ (not the 4. over-expensive). I'm not promising it would solve your issue so don't buy it solely for this bug. But they're great devices to play around with. They can be left on 24/7 at a much lower power cost.  But please take my suggestion lightly and make sure it works for you.
The magichome app is awful and it just keeps getting worse. It recently added an ambient movie lighting feature using the phone's camera. But with ZERO explanation on its use. My 32 magichome devices fill the entirety of the little menu so I guess it's not meant for that many.  Not that I'd want to use their app anyways.
Let me know how those steps go.

Thanks for the quick response again.
After further testing with your plugin, the v6 did not respond reliably to color and brightness commands, and certain selections in the color wheel turned the lights off completely. I'm guessing this is the byte size of the messages being sent, as you described. Several of the devices (v6 always, but also v4s) were not seen over multiple restarts, but continued to respond to Home commands, really strange. Also strange, the device previously registered correctly as v6 in Homebridge last showed as v5 🙃
Just to clarify - I never restarted the router when switching the network interface the Mini uses to connect to the network. Not sure if that changes your troubleshooting suggestions. Re: Raspberry Pi, I use the Mini for other things like Plex so it's already on 24/7, I'd prefer to keep Homebridge running there. I may eventually want to use PiHole in which case maybe it can do double duty.
Each time I re-added the problem v6 controller in the MagicHome app it was given the same IP it had been before. Just in case though I've set all 6 controllers (I discovered three more controllers, all showing firmware v2, installed elsewhere in our new rental home) to use static IP addresses.
I've removed your plugin and switched to homebridge-magichome-led as you suggested, which allows me to manually register each controller. Once all devices were registered, I turned wifi off on the Mini and have been able to maintain control of the controllers for the most part.
The v6 is still problematic in that it sometimes must be turned on in MagicHome before it can be controlled again in Homebridge or Home. After first turning off the wifi, all of the devices reported as offline, but after coaxing them a bit they now reliably show correctly.
I've starred and watched your repo and can hopefully return to it at some point - I do appreciate that it's a verified plugin. If there's any additional troubleshooting or testing I can do to help provide broader firmware/device support, I'm happy to help. I now have devices with firmware V2, V4, and V6.

Much appreciated. Could you tell me, what kind of controller is the V4 and V6. How many pins does it have, including ground? Just RGB?

I snapped some photos of the V6 and one of the V4s, both have 4 pins. RGB and what I assume is the ground.
V4:

V6:

Generally seeing lots of 'no response' messages in Home for both V4s and the V6 until I refresh a few times or jump into the Magichome app, while the V2s work flawlessly with this other plugin. Also still having more pronounced connection issues with the V6 in Homebridge, possibly due to using the incorrect model number? Here's what that looks like (I know this isn't your plugin, but maybe it will help if/when you expand model/firmware support) Error: connect ETIMEDOUT <IP_ADDRESS>:5577

Hi, @tedcarstensen. I've updated the plugin with some better version detection.
Please update in config ui x > plugins > homebridge-magichome-dynamic-platform > update
(!Important!) Next purge all magic-home accessories by going to config ui x > plugins > homebridge-magichome-dynamic-platform > settings > checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge at least twice > un-checkmark "Prune All Accessories Next Restart (Warning Dangerous!)" > restart homebridge
Let me know how this goes? Should improve things for your v4.

Thanks @Zacknetic and sorry it took a few weeks to respond here. I've switched back to your plugin and am experiencing great reliability with the V4s and especially the V2s compared to the other plugin. Thank you!
At this point it seems that the V6 is a lost cause and I'm better off buying another controller to swap in? I'll look at Amazon now, hopefully I don't end up with another V6!

I HIGHLY suggest you buy one of the MagicHome controllers which can control at least 1 white channel RGBW or even two white channels RGBWW. The LED strips aren't too expensive for these and it allows for some beautiful mixed color and white blends.
If you'd like amazon / aliexpress suggestions please let me know.
I'm sorry to hear that about the v6. Sometimes these things are just out of my control.


PgVectorAgroalPoolInterceptor doens't allow other profiles to be used while creating vector related attributes

I have a project where our profile name is local. While using quarkus langchain, with dev profile, necessary pgvector databases and extensions are added to the database. Since our profile is called as local am unable to find a way to override this behavior and build the same with devservices. Any directions here on how to workaround this?

Unfortunately I don't really understand what you are trying to do. Can you elaborate further?
cc @jmartisk

Do you mean that you need to get the CREATE EXTENSION IF NOT EXISTS vector query executed when the running Quarkus profile is named local?

Yes. @jmartisk that's what am trying to do.

Ok, I think it makes sense - how about we add a new boolean property quarkus.langchain4j.pgvector.register-vector-pg-extension that controls this, and it will be by default true only when running in dev or test mode, and can be explicitly turned on for other profiles too?

It would be really helpful if it's that way.

@jmartisk https://github.com/quarkiverse/quarkus-langchain4j/pull/1140/files would something like this help?


Feature: Bukkit port

Stonks is a global market for players, which means it only useful if you put this mod in your multiplayer servers.
Now it is worth nothing that the majority of servers are using Bukkit/Spigot forks (Paper is the most popular), which does not allow loading mods. Yes you can try to use cursed hybrid fork/mods (Cardboard or Mohist or whatever that is), but it is likely going to break your plugins or mods (especially with plugins that uses NMS).
The main goal of this proposal is to make Stonks for Bukkit port, which allows more servers to use Stonks instead of whatever paid plugins out there, as well as discouraging people from using cursed hybrid Spigot forks.
Some tasks should be finished before porting to Bukkit:

[ ] #1
[ ] #25
[ ] #46
[ ] #39
[ ] TODO

However, I wanted to collect feedbacks and have a discussion from users before deciding to make a Bukkit port, because this task is time consuming and I don't want to waste time on something that likely won't be used by me or large number of users in the future. After all, I made Stonks for Fabric so I can have a market for my Fabric server.

With the introduction of #46, the Bukkit port should be less painful than I initially thought. I also want to roll out the Bukkit port because I need it.
One thing to note is that the Bukkit port will be NMS-free. Or in other words, it will be fully API driven, using the latest API (Bukkit API 1.20 to be exact).


types broken when selecting '*' with foreign object

db.table.select('*') // typed correctly 🟢

db.table.select('*', someForeignObject: (q) => q.foreignObject) // types go "never" ❌

db.table.select('explicit', 'field', 'names', someForeignObject: (q) => q.foreignObject) // typed correctly 🟢

db.table.select('*', someForeignObject: (q) => q.foreignObject) // types go "never" ❌

This is invalid Typescript, it won't even compile. Please paste the actual code you're writing.
This should work:
db.table.select('*', { someForeignObject: (q) => q.foreignObject })

If it doesn't, please paste your respective table definitions.

my bad  @IlyaSemenov
it seems to be working fine now


Support connecting multiple OCP clusters on RHOS using Submariner

Epic Description
Support connecting multiple OCP clusters on RHOS using Submariner.
Why is this needed:
The aim of this proposal is to list and track steps needed to fill any gaps and allow full support for such deployments.
Acceptance Criteria
Should be able to prepare and deploy submariner in RHOS using subctl and cloud-prepare.
Definition of Done (Checklist)

[ ] Code complete
[ ] The acceptance criteria met
[ ] Unit/e2e test added & pass
[ ] CI jobs pass
[ ] Deployed using cloud-prepare+subctl
[ ] Deployed using ACM/OCM addon
[ ] Deployed on supported platforms (for e.g kind, OCP on AWS, OCP on GCP)
[ ] Run subctl verify, diagnose and gather
[ ] Uninstall
[ ] Troubleshooting (gather/diagnose) added
[ ] Documentation added
[ ] Release notes added

Work Items

[x] Deploy using cloud prepare and subctl on existing OCP clusters on RHOS https://github.com/submariner-io/submariner-operator/issues/1725
[x] Enhance cloud-prepare to support deploying dedicated Gateway nodes on RHOS - https://github.com/submariner-io/cloud-prepare/issues/167
[x] Enhance cloud-prepare to support configuring existing worker nodes as GW nodes on RHOS -  https://github.com/submariner-io/cloud-prepare/issues/166
[ ] Deploy using OCM and submariner-addon
[ ] Add UT
[ ] Support and run subctl verify
[ ] Support and run subctl diagnose
[ ] Support and run subctl gather
[ ] Remove cluster from multcluster using subctl
[ ] Remove cluster from multicluster using OCM and submariner-addon
[ ] Uninstall submariner using subctl
[ ] Uninstall submariner using OCM and submariner-addon
[ ] UI support for troubleshooting etc. on OCM
[ ] Documentation for deployments and removal using cloud-prepare and subctl
[ ] Documentation for deployments and removal using OCM

See https://github.com/submariner-io/cloud-prepare/issues/19 for cloud-prepare

The addon and other tasks related to monitoring are pending.

Let's not also forget about docs.

@aswinsuryan I believe this is done at this point?


Bump version numbers for v0.8.1

What this PR does / why we need it:
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
Special notes for your reviewer:
Release note:

/retest

/cherrypick release-0.8
/release-note-none


Add support for MacOS

This adds support for MacOS #1 by reading from the preferences.plist file found in /Library/Preferences/SystemConfiguration/
Proxy exceptions are distinct for different network adapters. The ProxyConfigInternal structure contains the network adapter name for which the proxy is configured.

@mattico any update on this? I work with @banaru4 and we are currently using proxy-config with patches from this PR in a project we'd like to publish to crates.io (https://github.com/devolutions/siquery-rs/). Since we can't publish with references to a git repository, would it be possible to let us know if this PR has a chance of being merged soon? Since this project was inactive for two years, I assume it could be no longer actively maintain, so we offer our help in maintaining it officially.

Hi all, sorry for the late response. As you may have guessed I no longer need this library for my own use, so I haven't had any motivation to work on it.
I'd be happy to add you as an owner to crates.io/proxy-config and update the readme here to point to your new upstream repo. Since you've already fork-released proxy-cfg, this is dubiously useful but if you want the name just let me know.


Add new political swatch colours for 2019

Copied from Caroline's illustrator swatch, party names remain the same but have added the Brexit Party spelt 'brexit' and 'change'

That space is now removed and the sapshot done


gyp_xwalk: Reduce delta with gyp_chromium.py.

Sync with the upstream version of this file. This time there are not
many changes, other than the fact that the code upstream moved from
gyp_chromium to gyp_chromium.py.
List of relevant commits:

d9aaae0 Add 'build' directory to import path of gyp_chromium.
1eeaa32 Move logic of gyp_chromium into gyp_chromium.py

@darktears @pozdnyakov

lgtm


Reduce Developer Overhead of SBE Dependencies in Pre-SBE repos

If a repo is built before source-build externals (a pre-SBE repo), that repo runs the risk of introducing a prebuilt if source-build externals updates the component and removes the old version.
In order to prevent a prebuilt, it was originally thought that two versions of the component would have to exist in source-build externals: the old version use by the pre-SBE repo, and the new version. Once the VMR has been updated with the new SBE version, the VMR must be rebootstrapped so that the pre-SBE repo consumes the most recent version of the component instead of the old version. While this is a valid solution, it introduces a lot of developer overhead; the developer must maintain two versions of the component in SBE, monitor the flow of SBE into the VMR, rebootstrap the VMR, update the pre-SBE repo to consume the new version of the dependency, and remove the old version of the component from SBE.
A better way of doing this would be to have the pre-SBE repo define a version property for the dependency coming from SBE. Then, the repo's .proj file in the VMR should be updated so that the version property is overridden by the n-1 version of the repo. This approach allows the developer to only have to maintain a single version of the component in SBE and not have to manually rebootstrap the VMR.
To fix resolve this issue, two things must occur:

Update the documentation in source-build externals to describe this process
Update any pre-SBE repos using dependencies from SBE:

Define version properties for dependencies originating from SBE
Update the repo's .proj file in the VMR to consume the version defined in n-1.

Working to confirm if the version prop can be pulled from previous version props.
If it can be pulled from previous version props, I'm wondering if I would have to wait for my changes from https://github.com/dotnet/arcade/pull/14678 to be included in a rebootstrap in order to see the MicrosoftApplicationInsightsVersion prop show up in PVP?
On investigating the PVP for arcade, I didn't see MicrosoftApplicationInsightsVersion in the file.

The extra version property would required msbuild logic to retrieve the version from n-1. I discussed this with @mmitche, and we both felt this was not desirable and that the preferred solution is to use the existing Version.Details.xml construct.  Yes it is a bit odd because the dependency is external but it is the better solution.  We should comment this dependency well.  If this becomes a common pattern it may warrant a new type of  Version.Details.xml dependency - e.g. ExternalDependencies.


Rainbows Works with Python Markdown

Making Rainbows work with Python-Markdown is surprisingly easy. You just have to enable Markdown extra and make this one edit to the /extensions/fenced_code.py file. Of course, adding the stylesheets and javascript to the template still applies. I thought some of your other users might be interested. All the best.

Closing this out since it is not actually a bug


'no handler found for uri' for certificate api

Certificate API in security plugin says its introduced in 1.0, but I tested in version 1.3.4 and 2.0 that:
GET _plugins/_security/api/ssl/certs is available in 2.0 and 2.2 but not in 1.3.4
PUT _opendistro/_security/api/ssl/http/reloadcerts is unavailable in either one
Error message:

~ $ GET /_plugins/_security/api/ssl/certs
{
"error": "no handler found for uri [/_plugins/_security/api/ssl/certs] and method [GET]"
}

~ $ PUT /_opendistro/_security/api/ssl/http/reloadcerts
{
"error": "no handler found for uri [/_opendistro/_security/api/ssl/http/reloadcerts] and method [PUT]"
}

Is this expected?

Turns out plugins.security.ssl_cert_reload_enabled should be True.
Better to add that to doc.


Update FlyBase disease and GO tsv files

Currently dumping data from our 2016_05 release for the old disease / go tsv files. This will better match the gene data (also from release 2016_05).

If we are going to update this files they need to be put in S3 and not checked into the project.

Will do.


Update Paper Plugins docs

Closes #174

Closes #183

Resolved Owens Comments

Ready for final review

Thanks, Addressed comments

Addressed, thanks


UNIT ISSUE

Name (Abbreviation) of the unit you want to create?
Stones to KG
What is its base SI unit?
KG
Would you like to provide more information about your unit?
No response
Contributor Guide

[X] I will comply with the Contributor Guide

Code of Conduct

[X] I have read and agree to the project's Code of Conduct

That's a great idea. slay


Error  CREATE_FAILED: FargateTasksCluster

Hi im trying out your plugin that looks really nice :)
But on build i am getting this error. am i doing something wrong?
CREATE_FAILED: FargateTasksCluster (AWS::ECS::Cluster)
Resource handler returned message: "Invalid request provided: CreateCluster Invalid Request: Unable to assume the service linked role. Please verify that the ECS service linked role exists. (Service: AmazonECS; Status Code: 400; Error Code:

Reading through the docs. it seems as though it could be due to the permissions the role/user has that is attempting to create the cluster? https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using-service-linked-roles.html


none: adding some basic mail related config fs ft

notmuch
mbsync
msmtp

There's already an msmtprc syntax file distributed with the code: https://fossies.org/linux/msmtp/scripts/vim/msmtp.vim

@ericpruitt oh, thank you, i do not know, and seems it did not include in vim code base, and looks you were the author of this syntax file, would you mind i include it within this PR, or you would do it by youself, or neither?
// for now this PR is just for basic syntax, if you have professional one, then would be better.

@ericpruitt perhaps this time let it just be for basic one,
// vs you can change it to your version when you have time and if ok to include it to vim code base,
// and i supposed you have others runtime files for mstmp too (other than syntax).
so this PR should be ready.

thanks!

Thanks, I'll make it then 'mstmp' for '.msmtprc', without including a syntax file. @ericpruitt feel free to submit your that syntax file for distribution with Vim. Thanks!

This now  moved to ~/.config/msmtp/config. See also https://github.com/marlam/msmtp/pull/148/files

it actually was a symblic ~/.msmtprc, or anyway:
diff --git a/runtime/filetype.vim b/runtime/filetype.vim
index 927230d4f..7da453365 100644
--- a/runtime/filetype.vim
+++ b/runtime/filetype.vim
@@ -1433,12 +1433,13 @@ au BufNewFile,BufRead *.mix,*.mixal		setf mix

 " MMIX or VMS makefile
 au BufNewFile,BufRead *.mms			call dist#ft#FTmms()

 " msmtp
 au BufNewFile,BufRead .msmtprc			setf msmtp
+au BufNewFile,BufRead */.config/msmtp/config	setf msmtp

 " Symbian meta-makefile definition (MMP)
 au BufNewFile,BufRead *.mmp			setf mmp

 " ABB Rapid, Modula-2, Modsim III or LambdaProlog
 au BufNewFile,BufRead *.mod\c			call dist#ft#FTmod()

--
shane.xb.qian


Markup Extensions :) :) :)

I have been thinking lately that I would be remiss to spend so much time and energy on this project and not enable markup extensions, my favorite feature from Xaml.  This would in effect make EXS as a Xaml parser in addition to being a XML POCO parser.
This should be an extension, obviously.  FWIW while I am not the happiest with the ConfigurationAPI (I'd rate it like 6/10), I am very happy with the ExtensionModelAPI (an 8 or 9 out of 10).  Lots of cool stuff there and I think it's a great new way to look at serialization. 👍

I like your changes in Configuration, but I don't know what you want to do in this issue .

So Markup Extensions are an awesome feature of Xaml that allow you to provide runtime values for a property while the object is being serialized.  They also allow you to tie into the object that is being serialized so that you can do cool things with it as time goes on (like binding).
Super simple example here:
public class MyMarkupExtension : IMarkupExtension
{
	public object ProvideValue(IServices services) => "Hello World"; // <-- could be from a web service or anywhere.
}

class Instance
{
	public string PropertyValue { get; }
}

<Instance PropertyValue="{x:MyMarkup}" />

var serializer = new ExtendedConfiguration().Create();
var actual = serializer.Deserialize<Instance>();
Assert.Equal( actual.PropertyValue, "Hello World!");

Another scenario could be how we use references.  Instead of using custom attributes (exs:reference/identity), we could use markup extensions instead. That's how Xaml does it. :)

OK this took a little longer than expected, but we now have a very simple implementation of markup extensions with core support for default framework markup extensions such as Null, Type, and Static.  Basically got done in one week what the entire UWP group has taken nearly seven years to do. ;)
Example of the static extension can be seen here.
Please note that in addition to specifying strings for values within a markup extension, I took it one step further so that you can use actual .NET/C# expressions within it.  So let's say you have an extension like this:
sealed class NumberExtension : IMarkupExtension
{
	readonly int _number;

	public NumberExtension(int number)
	{
		_number = number;
	}

	public object ProvideValue(IServiceProvider serviceProvider) => _number;
}

sealed class Subject
{
	public int Number { get; set; }
}

You are able to use it in your markup as such:
<?xml version="1.0" encoding="utf-8"?>
<Subject xmlns="clr-namespace:YourNamespace;assembly=YourAssembly" PropertyName="{Number 3 * 4}" />

var subject = new ExtendedConfiguration().EnableMarkupExtensions().Create().Deserialize<Subject>(xml);
subject.Number.Should().Be(12);

Cool huh!  Unfortunately (or fortunately, depending on your perspective :) ), in order to do this, we had to take on a dependency.  Currently, it is using the very powerful and handy Eval-Expression.NET.  It is free for the first 50 characters.  I am in communication with @JonathanMagnan in regards to this to see if we can somehow get a pro version if we give it special mention/thanks in our README.  Jonathan has said that they should have something together by Monday to discuss.
Also a consideration here Jonathan (and feel free to reply here): currently we are using all of our dependencies inline.  So we currently have two dependencies in Sprache and LightInject.  Both of them have been placed in our Core folder with licenses provided for both.
Will this be OK for your project as well?
I will be closing this issue to mark as done for now to get it off our list towards the milestone.  Please feel free to continue to comment.

Build failed ;)
There is log: https://ci.appveyor.com/project/wojtpl2/extendedxmlserializer/build/72

Hah!  It sure did.  Is there a notification for this, perhaps?  Seems like an important one to know. :)
The break is actually due to Eval-Expression.NET.  It looks for a new package at the start of every month.  I believe this is what Jonathan and team are looking for in our case here.
I just committed a fix.  HERE GOES NOTHING!! 😆

OK this looks like this is working as expected now.  Let me know if it is otherwise.


Not working on windows...

I am getting an error when trying to run on Windows 7.  I will try to debug it to get more info...
C:\test>ticons splashes -t -d .\output "xhdpi (640x960).png"
[INFO]  Reading input dimensions

events.js:72
        throw er; // Unhandled 'error' event
              ^
Error: spawn ENOENT
    at errnoException (child_process.js:1011:11)
    at Process.ChildProcess._handle.onexit (child_process.js:802:34)

Seems to be an issue w/ gm not ticons-cli.
You can close this issue.  Thanks!


Generate a msw mock server for testing

It would be awesome for testing if effect-http could generate an msw server for testing purposes w/ fast-check arbitrary data. Or maybe just make it easier to create one yourself.
https://www.npmjs.com/package/msw

Hey, I don't know this one but it looks pretty cool 👍. As I don't have any experience with the lib and unfortunately I probably won't have a use-case for it myself right now, it would honestly take some time for me to get to it. That being said, if you have know the library and would be up for it, feel free to prepare a new package in this monorepo. We could expose it as a new effect-http-msw package. WDYT?


Ensure that a Secret label value does not exceed 63 length

Changes
I have Knative and Istio together with net-istio running, and I created a domain mapping with a referenced TLS secret that has a name that exceeds 63 characters. Knative Net-Istio tries to synchronize this secret to the istio-system namespace and fails because it uses the secret name as label value:
Failed to create Secret istio-system/areallyverylongdomainnamethatexcd8923dee789a086a0ac46d3046cbec7-9c37460d-0d61-4f36-a65a-398b49d40f48: Secret "areallyverylongdomainnamethatexcd8923dee789a086a0ac46d3046cbec7-9c37460d-0d61-4f36-a65a-398b49d40f48" is invalid: metadata.labels: Invalid value: "areallyverylongdomainnamethatexceeds63charactersintotal.somethinglong.com": must be no more than 63 characters

I am changing the logic depending on the length of the secret name:

Nothing changes for secrets with a name length up to 63 characters. This ensures that all existing synchronized secrets can still be matched to the origin secret.
For a secret with a name length larger than 63 characters, I am putting the secret name into an annotation because there is logic that must identify the origin secret from the copy and therefore needs the secret name. I am putting in a 63 characters length label value using a hash. This is necessary for the deletion case where it must find the copy in the istio-system namespace based on a label selector.

/kind bug
Release Note
You can now reference secrets with name that has a length longer than 63 characters in a domain mapping

Docs
N/A

Looks like a fix to a bug we didn't know we had yet, thanks!
cc @nak3


Provide 7.9.3 chart

Describe the feature:
Update chart with latest version
Describe a specific use case for the feature:
run latest by default (Yes I know I can change the values)

Hi @davidkarlsen 7.9.3 charts have been released along with the Elastic Stack:

awesome - thanks a lot!


Additionals: Added maxsize plugin

We recently created a maxsize plugin to detect that a file is too large before submission. Based off of #450 and #1111, it looks like other people would like it as well. In this PR:

Added maxsize plugin into src/additional

Missing:
We didn't add any tests as there are no tests for the only other FileList based plugin (accept.js). I am assuming that the reason for this is we cannot programmatically tell a browser where to get our file uploads from.

Thank you for the contribution. This looks like a good start, but very much needs tests. There is an open PR that added tests for the accept method (#1373) and one more that further extends the method (#1441). Both need some rebasing or other fixes to get merged. Could I interest you in that? If so, start with the accept PRs (rebase and whatever else is needed), then rebase this PR on top and share the testing infrastructure (the acceptFileDummyInput function).

imo, per-computer filetype validation isn't too trustworthy as it can change a lot from computer to computer (e.g. we have seen .pdf with the type of application/download, www/unknown, application/x-pdf). As a result, I would prefer to stay away from #1441 and its edge cases.
Is there anything that needs to be done in #1373 aside from a squash/rebase?

No, I think that's all there is to it.

Is there any reason why I should do it over you? I am not quite sure I follow the problem =/ The attribution should still be preserved -- here is an example in jscs: https://github.com/jscs-dev/node-jscs/commit/18b4ffce821f03ab04b7df97949ddacedae315a1

If you are unfamiliar with how to grab commits from a PR outside of GitHub, here is a gist describing the details:
https://gist.github.com/piscisaureus/3342247

The problem are the 7 commits on that PR, of which at least three produce conflicts during a rebase. I figured you could help resolve those, since you'd likely end up integrating some of those changes into your own PR anyway.

Taking a shot at getting #1373 back on its feet

Please look at #6834.

This PR was opened over a year ago, I no longer work at the organization I started it from, and I no longer have time to contribute to this PR. Closing this PR -- someone can pull over the changes into another PR if they want them


Checking to make sure a file is selected

An unhandeled exception it thrown when the upload button is clicked without selecting a file to upload, it's not a big deal but it would be nice to fix! Maybe disable the button unless a file is selected.

Thank you @oussamabonnor1, I fixed it by adding a "required" attribute to the file input. (Handled in the front end)


SWA cannot authorize into linked API on staging environment

Describe the bug
I get a 401 when I try to access the API after linking it instead of having it managed.
I have deployed the existing api folder in my vs code project (that was earlier deployed as mangaged api and working) to a function app.
The api function app is running a node environment on windows and tested unauthorized. e.g. < API >/api/< functionname > works without authorization..
Both the AppServiceAuthSession and the StaticWebAppsAuthCookie cookies are in the rejected request.
I am using a custom B2C provider in the SWA staticwebapp.config.json
Maybe I need to setup the B2C identity provider in conjunction with the automatically created "Azure Static Web Apps (Linked)" provider in the authorization setup on the function app, but I can't find any documentation on this?
I am setting it up exclusively on the staging environment (before moving the setup to production). Could that be an issue?
Are there any other issues I need to be aware of to get authorized into the API function app on the staging environment with a B2C identity provider?
To Reproduce

Have an external identity provider setup for the SWA
Setup a linked API for the preview (staging) environment

Expected behavior
no 401 ;)
Additional context
For some odd reason the api/roles endpoint works ok?
It's a vanilla SPA
staticwebapp.config.json:
{
"routes": [
{
"route": "/",
"allowedRoles": [
"authenticated"
],
"headers": {
"Cache-Control": "no-store"
}
}
],
"responseOverrides": {
"401": {
"statusCode": 302,
"redirect": "/.auth/login/aadb2c"
}
},
"navigationFallback": {
"rewrite": "index.html",
"exclude": [
"/content/.{png,jpg,gif}"
]
},
"auth": {
"rolesSource": "/api/roles",
"identityProviders": {
"customOpenIdConnectProviders": {
"aadb2c": {
"registration": {
"clientIdSettingName": "AADB2C_PROVIDER_CLIENT_ID",
"clientCredential": {
"clientSecretSettingName": "AADB2C_PROVIDER_CLIENT_SECRET"
},
"openIdConnectConfiguration": {
"wellKnownOpenIdConfiguration": "https://##B2Ctenant##.b2clogin.com/##B2Ctenant##.onmicrosoft.com/B2C_1_SignIn/v2.0/.well-known/openid-configuration"
}
},
"login": {
"nameClaimType": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name",
"scopes": ["openid", "profile", "offline_access"],
"loginParameterNames": []
}
}
}
}
}
}
relevant part of azure pipeline:

task: AzureStaticWebApp@0
displayName: "Building and deploying to Staging"
condition: eq(variables['Build.SourceBranchName'], 'staging')
inputs:
app_location: "/"
api_location: ""
app_build_command: "npm run build"
output_location: "dist"
azure_static_web_apps_api_token: $(DEPLOYMENT-TOKEN)
production_branch: 'main'

Ok..  Found the root.. Functions are by default set to  "authLevel": "function" that SWA handles behind the scene. I am not sure if this setting is necessary with managed API? Anyways it makes no sense with a linked API as it would require the keys to be exposed in the frontend and SWA takes care of authentication into the linked API, so setting "authLevel":"anonymous" on all functions solved the issue.


[API] Get the state of history experiments

Feature Request
/experiments/history/state: Get the state of history experiments
See here for details

This is not clear to me. What is the difference between archive and history experiments? I think they are the same.


Uvicorn - Add to Project doesn't work

Confirmed on Windows and Linux
When adding a tap to the project I get a failure

2022-06-27T21:30:17.510848Z [error    ] Exception on /api/v1/plugins/install/batch [POST]
Traceback (most recent call last):
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask/app.py", line 2447, in wsgi_app
    response = self.full_dispatch_request()
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask/app.py", line 1952, in full_dispatch_request
    rv = self.handle_user_exception(e)
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask_restful/__init__.py", line 271, in error_router
    return original_handler(e)
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask_restful/__init__.py", line 271, in error_router
    return original_handler(e)
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask/app.py", line 1821, in handle_user_exception
    reraise(exc_type, exc_value, tb)
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise
    raise value
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask/app.py", line 1950, in full_dispatch_request
    rv = self.dispatch_request()
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/flask/app.py", line 1936, in dispatch_request
    return self.view_functions[rule.endpoint](**req.view_args)
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/meltano/api/security/auth.py", line 125, in decorated
    return f(*args, **kwargs)
  File "/home/visch/.local/pipx/venvs/meltano/lib/python3.8/site-packages/meltano/api/controllers/plugins.py", line 151, in install_batch
    related_plugins = add_service.add_related(plugin)
AttributeError: 'ProjectAddService' object has no attribute 'add_related'

@visch - Thanks for raising this. Looks like we removed add_related() but missed this ref.


Create a good README

create a readme to give a broder perspevtive about the project and scope of project

attribute hashnode and planetscale

closed with #5


Fixed flutter create "package" template error in pubspec.yaml

Attempted to resolve issue #14975
I've edited "package" template's pubspec.yaml similar to "create"'s one.

This is a better fix than @tvolkert's fix in https://github.com/flutter/flutter/pull/14976. :-)

Will land on green.

cla/google was confused. Both committers are OK.
flutter-build seems confused. Build is green.
I'm landing.