Unable to provision 7g.40gb slice on A100 40GB

I was trying to create dynamic slices with instaslice on a openshift cluster which has a node with 4 A100 GPU's. I found that instaslice is creating MIG for any config less than 7g.40gb but it's not able to create a MIG for 7g.40gb
I have tried the same workload with 7g.40gb and 4g.20gb slice and here are the details.
Instaslice image built from the branch release-4.19
[abharath@abharath-thinkpadt14sgen2i instaslice-operator]$ git branch
  main
* release-4.19

Node allocatable resources:
Allocatable:
  cpu:                                             127500m
  ephemeral-storage:<PHONE_NUMBER>26
  hugepages-1Gi:                                   0
  hugepages-2Mi:                                   0
  instaslice.redhat.com/accelerator-memory-quota:  160Gi
  instaslice.redhat.com/mig-1g.10gb:               16
  instaslice.redhat.com/mig-1g.5gb:                28
  instaslice.redhat.com/mig-1g.5gb+me:             28
  instaslice.redhat.com/mig-2g.10gb:               12
  instaslice.redhat.com/mig-3g.20gb:               8
  instaslice.redhat.com/mig-4g.20gb:               4
  instaslice.redhat.com/mig-7g.40gb:               4
  memory:<PHONE_NUMBER>Ki
  nvidia.com/gpu:                                  0
  nvidia.com/mig-3g.20gb:                          0
  nvidia.com/mig-4g.20gb:                          0
  pods:                                            250

Instaslice controller logs:
{"level":"info","ts":"2024-11-27T09:22:26.337021649Z","caller":"controller/instaslice_controller.go:443","msg":"no suitable node found in cluster for ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-j84fc","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-j84fc","reconcileID":"4991cd22-fe6f-4832-b820-a856ea5f01da","pod":"human-eval-deployment-job-j84fc"}
{"level":"info","ts":"2024-11-27T09:22:36.337786468Z","caller":"controller/capacity.go:48","msg":"cpu request obtained ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-j84fc","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-j84fc","reconcileID":"a1cecafe-2a40-414b-8b22-38ad0698d2ea","pod":"human-eval-deployment-job-j84fc","value":2}
{"level":"info","ts":"2024-11-27T09:22:36.337871857Z","caller":"controller/capacity.go:56","msg":"memory request obtained ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-j84fc","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-j84fc","reconcileID":"a1cecafe-2a40-414b-8b22-38ad0698d2ea","pod":"human-eval-deployment-job-j84fc","value":4294967296}
{"level":"info","ts":"2024-11-27T09:22:36.337903101Z","caller":"controller/instaslice_controller.go:443","msg":"no suitable node found in cluster for ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-j84fc","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-j84fc","reconcileID":"a1cecafe-2a40-414b-8b22-38ad0698d2ea","pod":"human-eval-deployment-job-j84fc"}

workload yaml:
kind: Namespace
metadata:
  name: kruize-gpu-rec-apply
---
kind: Job
apiVersion: batch/v1
metadata:
  name: human-eval-deployment-job
  namespace: kruize-gpu-rec-apply
spec:
  template:
    spec:
      containers:
        - name: human-eval-benchmark
          image: 'quay.io/kruizehub/human-eval-deployment:latest'
          env:
            - name: num_prompts
              value: '20000'
          resources:
            requests:
              cpu: 2
              memory: 4Gi
              nvidia.com/mig-7g.40gb: 1
            limits:
              cpu: 2
              memory: 4Gi
              nvidia.com/mig-7g.40gb: 1
          volumeMounts:
            - name: cache-volume
              mountPath: /.cache/huggingface
          imagePullPolicy: IfNotPresent
      restartPolicy: Never
      volumes:
        - name: cache-volume
          persistentVolumeClaim:
            claimName: cache-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cache-pvc
  namespace: kruize-gpu-rec-apply
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 2Gi

Workload status:
[abharath@abharath-thinkpadt14sgen2i nerc]$ oc get pods -n kruize-gpu-rec-apply
NAME                              READY   STATUS            RESTARTS   AGE
human-eval-deployment-job-j84fc   0/1     SchedulingGated   0          5s

describe pod output:
[abharath@abharath-thinkpadt14sgen2i nerc]$ oc describe pod human-eval-deployment-job-j84fc -n kruize-gpu-rec-apply
Name:             human-eval-deployment-job-j84fc
Namespace:        kruize-gpu-rec-apply
Priority:         0
Service Account:  default
Node:             <none>
Labels:           batch.kubernetes.io/controller-uid=6663a528-6986-4fb6-8567-c7bb5a913ddf
                  batch.kubernetes.io/job-name=human-eval-deployment-job
                  controller-uid=6663a528-6986-4fb6-8567-c7bb5a913ddf
                  job-name=human-eval-deployment-job
Annotations:      openshift.io/scc: restricted-v2
                  seccomp.security.alpha.kubernetes.io/pod: runtime/default
Status:           Pending
SeccompProfile:   RuntimeDefault
IP:
IPs:              <none>
Controlled By:    Job/human-eval-deployment-job
Containers:
  human-eval-benchmark:
    Image:      quay.io/kruizehub/human-eval-deployment:latest
    Port:       <none>
    Host Port:  <none>
    Limits:
      cpu:                                             2
      instaslice.redhat.com/accelerator-memory-quota:  40Gi
      instaslice.redhat.com/mig-7g.40gb:               1
      memory:                                          4Gi
    Requests:
      cpu:                                             2
      instaslice.redhat.com/accelerator-memory-quota:  40Gi
      instaslice.redhat.com/mig-7g.40gb:               1
      memory:                                          4Gi
    Environment Variables from:
      982d3f10-36c6-4bca-b8a0-6b596a353e83  ConfigMap  Optional: false
    Environment:
      num_prompts:  20000
    Mounts:
      /.cache/huggingface from cache-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-smdnc (ro)
Conditions:
  Type           Status
  PodScheduled   False
Volumes:
  cache-volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  cache-pvc
    ReadOnly:   false
  kube-api-access-smdnc:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
    ConfigMapName:           openshift-service-ca.crt
    ConfigMapOptional:       <nil>
QoS Class:                   Guaranteed
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:                      <none>

Note: it's working if I change nvidia.com/mig-7g.40gb: 1 in requests and limits to nvidia.com/mig-4g.20gb: 1
Controller logs when tried with 4g.20gb:
{"level":"info","ts":"2024-11-27T09:23:28.514660632Z","caller":"controller/instaslice_controller.go:203","msg":"finalizer deleted for failed for ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-j84fc","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-j84fc","reconcileID":"27a11b3d-f8af-4fb2-9c2e-28d9bff3f2f8","pod":"human-eval-deployment-job-j84fc"}
{"level":"info","ts":"2024-11-27T09:24:15.329605712Z","caller":"controller/capacity.go:48","msg":"cpu request obtained ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-xs4tz","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-xs4tz","reconcileID":"6a951761-a3e8-44ae-b15e-cff383da295d","pod":"human-eval-deployment-job-xs4tz","value":2}
{"level":"info","ts":"2024-11-27T09:24:15.329719412Z","caller":"controller/capacity.go:56","msg":"memory request obtained ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-xs4tz","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-xs4tz","reconcileID":"6a951761-a3e8-44ae-b15e-cff383da295d","pod":"human-eval-deployment-job-xs4tz","value":4294967296}
{"level":"info","ts":"2024-11-27T09:24:15.329761712Z","caller":"controller/instaslice_controller.go:427","msg":"allocation obtained for ","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-xs4tz","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-xs4tz","reconcileID":"6a951761-a3e8-44ae-b15e-cff383da295d","pod":"human-eval-deployment-job-xs4tz"}
{"level":"error","ts":"2024-11-27T09:24:15.594604284Z","caller":"controller/instaslice_controller.go:763","msg":"error ungating pod","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-xs4tz","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-xs4tz","reconcileID":"349e816d-b02e-4ba0-ba89-dc438e619177","error":"Operation cannot be fulfilled on pods \"human-eval-deployment-job-xs4tz\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"github.com/openshift/instaslice-operator/internal/controller.(*InstasliceReconciler).addNodeSelectorAndUngatePod\n\t/workspace/internal/controller/instaslice_controller.go:763\ngithub.com/openshift/instaslice-operator/internal/controller.(*InstasliceReconciler).Reconcile\n\t/workspace/internal/controller/instaslice_controller.go:400\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Reconcile\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:116\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:303\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:263\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func2.2\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:224"}
{"level":"info","ts":"2024-11-27T09:24:15.59478036Z","caller":"controller/controller.go:314","msg":"Warning: Reconciler returned both a non-zero result and a non-nil error. The result will always be ignored if the error is non-nil and the non-nil error causes reqeueuing with exponential backoff. For more details, see: https://pkg.go.dev/sigs.k8s.io/controller-runtime/pkg/reconcile#Reconciler","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-xs4tz","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-xs4tz","reconcileID":"349e816d-b02e-4ba0-ba89-dc438e619177"}
{"level":"error","ts":"2024-11-27T09:24:15.594807119Z","caller":"controller/controller.go:316","msg":"Reconciler error","controller":"InstaSlice-controller","controllerGroup":"","controllerKind":"Pod","Pod":{"name":"human-eval-deployment-job-xs4tz","namespace":"kruize-gpu-rec-apply"},"namespace":"kruize-gpu-rec-apply","name":"human-eval-deployment-job-xs4tz","reconcileID":"349e816d-b02e-4ba0-ba89-dc438e619177","error":"Operation cannot be fulfilled on pods \"human-eval-deployment-job-xs4tz\": the object has been modified; please apply your changes to the latest version and try again","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).reconcileHandler\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:316\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).processNextWorkItem\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:263\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller[...]).Start.func2.2\n\t/workspace/vendor/sigs.k8s.io/controller-runtime/pkg/internal/controller/controller.go:224"}

Daemonset logs after applying 4g.20gb:
{"level":"info","ts":"2024-11-27T09:24:15.345122243Z","caller":"controller/instaslice_daemonset.go:162","msg":"creating allocation for ","controller":"InstaSliceDaemonSet","controllerGroup":"inference.redhat.com","controllerKind":"Instaslice","Instaslice":{"name":"wrk-5","namespace":"instaslice-system"},"namespace":"instaslice-system","name":"wrk-5","reconcileID":"ff2dd559-f963-41fd-9a6b-c8ab7761ebc5","pod":"human-eval-deployment-job-xs4tz"}
{"level":"info","ts":"2024-11-27T09:24:15.345971011Z","caller":"controller/instaslice_daemonset.go:221","msg":"The profile id is","controller":"InstaSliceDaemonSet","controllerGroup":"inference.redhat.com","controllerKind":"Instaslice","Instaslice":{"name":"wrk-5","namespace":"instaslice-system"},"namespace":"instaslice-system","name":"wrk-5","reconcileID":"ff2dd559-f963-41fd-9a6b-c8ab7761ebc5","giProfileInfo":5,"Memory":19968,"pod":"b218f0de-b0b3-43b2-ba3e-06129faae25e"}
{"level":"info","ts":"2024-11-27T09:24:15.34631395Z","caller":"controller/instaslice_daemonset.go:881","msg":"creating slice for","controller":"InstaSliceDaemonSet","controllerGroup":"inference.redhat.com","controllerKind":"Instaslice","Instaslice":{"name":"wrk-5","namespace":"instaslice-system"},"namespace":"instaslice-system","name":"wrk-5","reconcileID":"ff2dd559-f963-41fd-9a6b-c8ab7761ebc5","pod":"human-eval-deployment-job-xs4tz"}
{"level":"info","ts":"2024-11-27T09:24:15.514907103Z","caller":"controller/instaslice_daemonset.go:717","msg":"ConfigMap not found, creating for ","controller":"InstaSliceDaemonSet","controllerGroup":"inference.redhat.com","controllerKind":"Instaslice","Instaslice":{"name":"wrk-5","namespace":"instaslice-system"},"namespace":"instaslice-system","name":"wrk-5","reconcileID":"ff2dd559-f963-41fd-9a6b-c8ab7761ebc5","name":"7d9c93e0-e9b0-4562-8b12-8678019a0a5b","migGPUUUID":"MIG-ae3fdfff-d866-5cd6-a79d-94902fa9c5a0"}
{"level":"info","ts":"2024-11-27T09:24:15.534308794Z","caller":"controller/instaslice_daemonset.go:251","msg":"done creating mig slice for ","controller":"InstaSliceDaemonSet","controllerGroup":"inference.redhat.com","controllerKind":"Instaslice","Instaslice":{"name":"wrk-5","namespace":"instaslice-system"},"namespace":"instaslice-system","name":"wrk-5","reconcileID":"ff2dd559-f963-41fd-9a6b-c8ab7761ebc5","pod":"human-eval-deployment-job-xs4tz","parentgpu":"GPU-15ea50a3-01fd-b823-2c66-0e247db67a7d","miguuid":"MIG-ae3fdfff-d866-5cd6-a79d-94902fa9c5a0"}

Pod running with 4g.20gb:
[abharath@abharath-thinkpadt14sgen2i nerc]$ oc get pods -n kruize-gpu-rec-apply
NAME                              READY   STATUS    RESTARTS   AGE
human-eval-deployment-job-xs4tz   1/1     Running   0          2m15s

Pod describe:
[abharath@abharath-thinkpadt14sgen2i nerc]$ oc describe pod human-eval-deployment-job-xs4tz -n kruize-gpu-rec-apply
Name:             human-eval-deployment-job-xs4tz
Namespace:        kruize-gpu-rec-apply
Priority:         0
Service Account:  default
Node:             wrk-5/<IP_ADDRESS>
Start Time:       Wed, 27 Nov 2024 14:54:16 +0530
Labels:           batch.kubernetes.io/controller-uid=e6faf00e-7d7e-4026-bac1-ea4c42d868d8
                  batch.kubernetes.io/job-name=human-eval-deployment-job
                  controller-uid=e6faf00e-7d7e-4026-bac1-ea4c42d868d8
                  job-name=human-eval-deployment-job
Annotations:      k8s.ovn.org/pod-networks:
                    {"default":{"ip_addresses":["<IP_ADDRESS>/23"],"mac_address":"0a:58:0a:81:04:35","gateway_ips":["<IP_ADDRESS>"],"routes":[{"dest":"<IP_ADDRESS>...
                  k8s.v1.cni.cncf.io/network-status:
                    [{
                        "name": "ovn-kubernetes",
                        "interface": "eth0",
                        "ips": [
                            "<IP_ADDRESS>"
                        ],
                        "mac": "0a:58:0a:81:04:35",
                        "default": true,
                        "dns": {}
                    }]
                  openshift.io/scc: restricted-v2
                  seccomp.security.alpha.kubernetes.io/pod: runtime/default
Status:           Running
SeccompProfile:   RuntimeDefault
IP:               <IP_ADDRESS>
IPs:
  IP:           <IP_ADDRESS>
Controlled By:  Job/human-eval-deployment-job
Containers:
  human-eval-benchmark:
    Container ID:   cri-o://b5747f5fc8ee06c42757f433742e6d50f9d183d32d9e868c9d71e5a528d4231c
    Image:          quay.io/kruizehub/human-eval-deployment:latest
    Image ID:       quay.io/kruizehub/human-eval-deployment@sha256:002649f767f242834c7349fd01d85f9929ef215fe7676bdf3cbc832049a130fd
    Port:           <none>
    Host Port:      <none>
    State:          Running
      Started:      Wed, 27 Nov 2024 14:54:21 +0530
    Ready:          True
    Restart Count:  0
    Limits:
      cpu:                                             2
      instaslice.redhat.com/accelerator-memory-quota:  20Gi
      instaslice.redhat.com/mig-4g.20gb:               1
      memory:                                          4Gi
    Requests:
      cpu:                                             2
      instaslice.redhat.com/accelerator-memory-quota:  20Gi
      instaslice.redhat.com/mig-4g.20gb:               1
      memory:                                          4Gi
    Environment Variables from:
      7d9c93e0-e9b0-4562-8b12-8678019a0a5b  ConfigMap  Optional: false
    Environment:
      num_prompts:  20000
    Mounts:
      /.cache/huggingface from cache-volume (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-dz6v9 (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       True
  ContainersReady             True
  PodScheduled                True
Volumes:
  cache-volume:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  cache-pvc
    ReadOnly:   false
  kube-api-access-dz6v9:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
    ConfigMapName:           openshift-service-ca.crt
    ConfigMapOptional:       <nil>
QoS Class:                   Guaranteed
Node-Selectors:              kubernetes.io/hostname=wrk-5
Tolerations:                 node.kubernetes.io/memory-pressure:NoSchedule op=Exists
                             node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type     Reason                  Age    From                     Message
  ----     ------                  ----   ----                     -------
  Warning  FailedScheduling        2m48s  default-scheduler        0/9 nodes are available: persistentvolumeclaim "cache-pvc" not found. preemption: 0/9 nodes are available: 9 Preemption is not helpful for scheduling.
  Normal   Scheduled               2m46s  default-scheduler        Successfully assigned kruize-gpu-rec-apply/human-eval-deployment-job-xs4tz to wrk-5
  Normal   SuccessfulAttachVolume  2m46s  attachdetach-controller  AttachVolume.Attach succeeded for volume "pvc-ba228d4b-9bca-4b31-9d71-1f670fb54427"
  Normal   AddedInterface          2m43s  multus                   Add eth0 [<IP_ADDRESS>/23] from ovn-kubernetes
  Normal   Pulled                  2m43s  kubelet                  Container image "quay.io/kruizehub/human-eval-deployment:latest" already present on machine
  Normal   Created                 2m42s  kubelet                  Created container human-eval-benchmark
  Normal   Started                 2m42s  kubelet                  Started container human-eval-benchmark

Thanks for this issue. Can you share nvidia-smi -L output before the slice creation and after slice creation.

Thanks @asm582 I'll try with the main branch build.


autoregistration: fix regression in PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION

This flag would currently cause Istiod to panic if its ever set. Fix it
and add a simple test

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
a1d35c5c605d5c6dda1d4f97cab36bf32f9fd7c6
link
true
/test unit-tests-arm64

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests-arm64_istio
a1d35c5c605d5c6dda1d4f97cab36bf32f9fd7c6
link
true
/test unit-tests-arm64

unit-tests_istio
a1d35c5c605d5c6dda1d4f97cab36bf32f9fd7c6
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@howardjohn: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name
Commit
Details
Required
Rerun command

unit-tests_istio
2fe0706237f4274c8065408fa6f5e0b63b379c47
link
true
/test unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Firebase works in Unity Editor not on Device / APK build

Please fill in the following fields:
Unity editor version: 2018.3.11f1
Firebase Unity SDK version: 5.4.4
Additional SDKs you are using (Facebook, AdMob, etc.): N/A
Platform you are using the Unity editor on (Mac, Windows, or Linux): Windows
Platform you are targeting (iOS, Android, and/or desktop): Android
Please describe the issue here:
Using the Firebase Auth and Realtime Database. I am able to send data via the Unity Editor, but when I create the build to test it on a device and click the Register Button, it doesn't create a new user.
Everything is a fresh install. I haven't moved any files.

@acoale
Are you able to reproduce this with Auth quickstart?
https://github.com/firebase/quickstart-unity/tree/master/auth/testapp
Also, you can use view the log on your Android device using the following command.
adb logcat
The log may show you more information about the problem.

So I resolved the issue on my own, I need better debugging messages.
Here have a good laugh...
04-04 15:17:07.044 32047 32073 I Unity   : (Filename: ./Runtime/Export/Debug.bindings.h Line: 45)
04-04 15:17:07.044 32047 32073 I Unity   :
04-04 15:17:07.335 32047 32073 E Unity   : CreateUserWithEmailAndPasswordAsync encountered an error: System.AggregateException: Exception of type 'System.AggregateException' was thrown.
04-04 15:17:07.335 32047 32073 E Unity   : -----------------
04-04 15:17:07.335 32047 32073 E Unity   : Firebase.FirebaseException: The email address is badly formatted.
04-04 15:17:07.335 32047 32073 E Unity   :
04-04 15:17:07.335 32047 32073 E Unity   :
04-04 15:17:07.335 32047 32073 E Unity   : (Filename: ./Runtime/Export/Debug.bindings.h Line: 45)

No problem.  Glad it is resolved!


feat: major API redesign (WIP)

Closes #694
Closes #699
Closes #714
Closes #748
Summary of Changes

Replace old implementation of tabular containers
New, more efficient implementation of metrics
Standalone package for metrics
New regression metrics
Abstract base class for classifiers & regressors
Introspection methods to get information about features and target of supervised models
Rename LogisticRegressionClassifier to LogisticClassifier (shorter + does not show up when searching for regression)
Rename LinearRegressionRegressor to LinearRegressor (shorter)
Rename SupportVectorMachineClassifier to SupportVectorClassifier (a little less precise, but still unambiguous and shorter)
Rename SupportVectorMachineRegressor to SupportVectorRegressor (ditto)

@Safe-DS/library Since this drastically alters the API, I'll merge it in this unfinished state. I'll fix linter issues and tests in the coming days before the next release.

:tada: This PR is included in version 0.25.0 :tada:
The release is available on:

v0.25.0
GitHub release

Your semantic-release bot :package::rocket:


Feature request: delete Secret when backend value is deleted

I would like to have KES delete secrets when an AWS SSM Parameter is deleted. The use case is so that we can set or unset secrets through SSM and that is reflected in the cluster.
The current behavior looks like this:

An externalSecret is created in the cluster pointing to /parameter1
KES creates a secret with the value of said parameter
delete /parameter1 in AWS console
the externalSecret goes to state  ERROR, ParameterNotFound: /parameter1 could not be found
the secret stays in the cluster and is not garbage collected

It would be nice to have an option similar to the "garbage-collection" that Flux implements. With this enabled, a missing parameter would trigger a deletion of the corresponding secret.

What happens if there are authentication issues or if an external secret references multiple values? Is it just the secret that should be removed or the external secret?
Currently secrets are left in the last "good" state indeed. A deletion of the external secret would also delete the secret.

What happens if there are authentication issues or if an external secret references multiple values? Is it just the secret that should be removed or the external secret?
Currently secrets are left in the last "good" state indeed. A deletion of the external secret would also delete the secret.

What happens if there are authentication issues or if an external secret references multiple values? Is it just the secret that should be removed or the external secret?
Currently secrets are left in the last "good" state indeed. A deletion of the external secret would also delete the secret.

What happens if there are authentication issues or if an external secret references multiple values? Is it just the secret that should be removed or the external secret?
Currently secrets are left in the last "good" state indeed. A deletion of the external secret would also delete the secret.

Hi @Flydiverny thanks for the prompt response! Good questions, I hadn't thought of all the use cases....

What happens if there are authentication issues

I guess if it had an annotation saying something like "garbage collect this" it should be removed when there are auth issues. I am thinking this could be useful when one wants to remove access to something by removing the source of the secret. In that case we might not want to keep a copy of that secret in the cluster. This is just a made up use case.

or if an external secret references multiple values?

Ideally the secret that is missing should be removed from the secret?

So a secret should only exist as long as an external secret is in a good status?

I was thinking this would be the case only when the external secret has that "garage collection" annotation. This also ensures backwards compatibility and no bad surprises.
What do you think? Can you think of a an alternative way I can achieve a similar outcome? I basically want to be able to remove a parameter from SSM and have it removed from the cluster automatically.

Hi @Flydiverny thanks for the prompt response! Good questions, I hadn't thought of all the use cases....

What happens if there are authentication issues

I guess if it had an annotation saying something like "garbage collect this" it should be removed when there are auth issues. I am thinking this could be useful when one wants to remove access to something by removing the source of the secret. In that case we might not want to keep a copy of that secret in the cluster. This is just a made up use case.

or if an external secret references multiple values?

Ideally the secret that is missing should be removed from the secret?

So a secret should only exist as long as an external secret is in a good status?

I was thinking this would be the case only when the external secret has that "garage collection" annotation. This also ensures backwards compatibility and no bad surprises.
What do you think? Can you think of a an alternative way I can achieve a similar outcome? I basically want to be able to remove a parameter from SSM and have it removed from the cluster automatically.

I guess if it had an annotation saying something like "garbage collect this" it should be removed when there are auth issues. I am thinking this could be useful when one wants to remove access to something by removing the source of the secret. In that case we might not want to keep a copy of that secret in the cluster. This is just a made up use case.

I have a requirement from infosec that if an AWS Secrets Manager secret is deleted, it should also be removed from the cluster within a reasonable time frame. One of the workarounds suggested is for AWS Secrets Manager secret to be null valued before being marked for deletion which would result into the credential being "removed" but it's too easy for someone to not follow the process which ends up with sensitive credentials "dangling" in the cluster.

AWS Secrets Manager enforces a minimum waiting period of 7 days to give you time to update your code. You will not be able to retrieve the secret if it is scheduled for deletion.

Some thoughts around this; during the waiting period (status as shown below indicates it's marked for deletion), perhaps leave the secret in a last "good" state but once the waiting period has elapsed, remove the secret. If the delete is cancelled, the external secret syncs as normal and the secret is kept up to date.
NAME                   LAST SYNC   STATUS                                                                                AGE
test   32m         ERROR, You can't perform this operation on the secret because it was marked for deletion.   9h

The external secret should be left behind with a status indicating that the backend was removed, perhaps with a metric endpoint to create visibility/setup alerting on.
If the external secret references multiple backend values, it becomes tricky. Ideally, the referenced properties/values should be removed from the secret, ensuring no sensitive information is left behind but this probably easier said than done and this probably warrants a deeper discussion.

I basically want to be able to remove a parameter from SSM and have it removed from the cluster automatically.

+1

For comparison, the Secrets Store CSI Driver deletes Secrets whenever they're no longer mounted in any Pods, even if it still exists in the backend. I'm not sure what it does if the Secret is in use but deleted on the backend, but in that case you'd have to cycle your pods anyway to get them to stop using the Secret, at which point the Secret would definitely be deleted.
But this kind of usage tracking is very different from the approach KES uses.
See  https://secrets-store-csi-driver.sigs.k8s.io/topics/sync-as-kubernetes-secret.html.

same issue on Secret Manager, the backend value has been updated and Secret is still using Outdated value


CharSet operator()( char ) should be noexcept

Is the whole abstraction of character sets necessary in the library that deals with urls? Is the set not hardcoded in the rfc? Or will I ever need to use lut_chars explicitly when dealing with urls?
And a more specific issue. The specs for function https://master.url.cpp.al/url/ref/boost__urls__validate_pct_encoding/overload1.html say that it throws nothig, but it uses  CharSet, and the concept does not require that its models must not throw. Even constexpr does not imply no-throw.

Is the whole abstraction of character sets necessary in the library that deals with urls? Is the set not hardcoded in the rfc? Or will I ever need to use lut_chars explicitly when dealing with urls?

The design of the library follows a "99/1" rule. Part of the public interface of the library is designed to satisfy 99% of users (url, url_view, static_url) while the rest of the public interface is designed to satisfy the 1%.
Note:

percent-encoding occurs in non-URL contexts
The reserved character set varies depending on the URL part
The reserved character set can vary by scheme

As most use-cases will be limited to the well-known schemes (http, https, ftp, ws, wss, file), most users will not see CharSets or need to interact with them. But if you start trying to implement other schemes on top of the library then you will eventually care. And if you want to do percent-encoding outside of URL contexts (such as in HTTP message bodies when using Content-Type: application/x-www-form-urlencoded) then you will need to be precise and specify a character set with the percent encoding and decoding free functions.
As the library designer I have made the choice to make the scope of the library a bit more broad that what someone might expect, because I am positioning this library as a foundational component for a family of libraries used to implement various protocols. That is why the algorithms for parsing have been formalized and documented. For example my in-development library Boost.HTTP.Proto uses the interfaces in the boost::urls::grammar namespace to parse the HTTP request-line:
https://github.com/vinniefalco/http_proto/blob/aae0a1055c4102c7241ef9c16a187addddbd7d30/include/boost/http_proto/rfc/detail/rules.hpp#L145
This begs the question, why isn't this proposed in a separate library? Four reasons: it would be too small, too overly specific, too limited, and too much overlap to existing libraries.
The other obvious question is "why not use Spirit" which I am sure will come up. There are many reasons:

Spirit does too much
Taking a dependency on a large Boost library turns away users
Keeping parsing in-house (i.e. as a leaf in the dependency graph) has security advantages
in-house algorithms are more suited to purpose. They are designed from the ground up with the needs of the library in mind.

The specs for function https://master.url.cpp.al/url/ref/boost__urls__validate_pct_encoding/overload1.html say that it throws nothig, but it uses CharSet, and the concept does not require that its models must not throw. Even constexpr does not imply no-throw.

I did think that constexpr was implicitly noexcept (was I wrong?). The CharSet concept should probably require noexcept for operator()( char ).
But the general answer here, is that if you look closely you will probably find more inconsistencies and documentation bugs. These need to be shaken out. My personal development process is one of rapid iteration and many changes over time, so I tend not to invest too heavily in specifications and documentation up front since those always change. Then towards the end (meaning, a week or two before review) when I know that things are stable is when I start doing many passes through documentation and interfaces to clean stuff up. It is also helpful when people point these things out as I don't always see them.

Part of this answer could go into the docs :)

constexpr only requires that there is only one combination of function parameters for which the function can return a compile-time constant. For all other values, it can do runtime things, including throwing exceptions.
constexpr requirement cannot be enforced statically via a concept or a type trait. Nor do you need the operation to be constexpr. It is just an encouragement.

or do you need the operation to be constexpr.

You mean on operator()? Yeah, there's no requirement or benefit for it being constexpr. But it should be noexcept


fix(ci): fix install protoc

I hereby agree to the terms of the Singularity Data, Inc. Contributor License Agreement.
What's changed and what's your intention?
Fix: protoc failed: google/protobuf/descriptor.proto: File not found.
https://buildkite.com/risingwavelabs/docker/builds/13287#0185bb52-dd2b-403d-8b33-010192eaf6f4

BTW, why release-env is a different env than rw-build-env? 👀 @huangjw806

BTW, why release-env is a different env than rw-build-env? 👀 @huangjw806

#4556 show the details of the reason


angular 1.3?

Has this directive been tested against angular 1.3? I am getting a race condition on 1.3 with the "resize()" function.

The race condition went away when I styled the height outside of the directive.

Yes - its working fine here under 1.3 and the github demo is using 1.3.6 and that also works fine.


fix(osfamilymap): fix no grains.init on *BSD (and enable CI for *BSD)

PR progress checklist (to be filled in by reviewers)

[ ] Changes to documentation are appropriate (or tick if not required)
[ ] Changes to tests are appropriate (or tick if not required)
[ ] Reviews completed

What type of PR is this?

Primary type

[ ] [build]    Changes related to the build system
[ ] [chore]    Changes to the build process or auxiliary tools and libraries such as documentation generation
[x] [ci]       Changes to the continuous integration configuration
[ ] [feat]     A new feature
[x] [fix]      A bug fix
[ ] [perf]     A code change that improves performance
[ ] [refactor] A code change that neither fixes a bug nor adds a feature
[ ] [revert]   A change used to revert a previous commit
[ ] [style]    Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.)

Secondary type

[ ] [docs]     Documentation changes
[ ] [test]     Adding missing or correcting existing tests

Does this PR introduce a BREAKING CHANGE?

No.
Related issues and/or pull requests

Fixes #38.
Describe the changes you're proposing

Also enable Vagrant-based testing using GitHub Actions:

Automated using https://github.com/myii/ssf-formula/pull/334

Pillar / config required to test the proposed changes

Debug log showing how the proposed changes work

Documentation checklist

[ ] Updated the README (e.g. Available states).
[ ] Updated pillar.example.

Testing checklist

[ ] Included in Kitchen (i.e. under state_top).
[ ] Covered by new/existing tests (e.g. InSpec, Serverspec, etc.).
[ ] Updated the relevant test pillar.

Additional context

:tada: This PR is included in version 0.12.1 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Logo added to Nav Bar

issue: #126
solved! i have added a logo that goes with the aesthetics of the website.

This branch has conflicts. A logo has been added if you can improve the logo then you may contribute in that.


Can you tell me your testing environment (eg, Android version..) and mobile device?

Hello,
What are your testing env and device, I will try to have the same , simulate or different one to test your lib.
I will share my testing result and We can keep forward together.
Regards,
Philip Chen

Hello,
My testing env is: Android 11, Android 12, device: Poco F1 , Samsung (I forgot the mobile). There is a known issue when i provide default sim it doesn't work. There was some issue in the Samsung device which i forgot now.
Regards
Dayananda Dowarah


Log to stdout in the Docker container

This PR reconfigures the Docker config to log to stdout.  It reconfigures SeeLog to log to the console, and uses the changes from #151 to stop the app from grabbing stdout/stderr and sending them to burrow.out.  I believe this change will create the behavior most users will expect when running in a Docker container.
Note that this PR is simply for the config changes, but relies on the code changes in #151.

This changes default behavior, but in this case I think it's OK. It will only break logging, and it's easy to fix.
Can you please also change the default config file that is provided to retain the default behavior.

Hi @toddpalino
This is why I broke this up into #151 and #152.  PR #151 has the code to allow stdout and stderr to be disabled.  This PR has #151 and the config change to change the default behavior.  If you're happy with the baseline configuration option that does not change the default behavior please merge #151, I was careful to retain default behavior there.
I opened this PR to focus on changing the default behavior, at least in the container.  As seen in issues like #112 not having logs in the container is confusing to users who don't know to go looking in /tmp/burrow/burrow.log.  The config change here is in docker-config/logging.cfg, which per the naming should be specific to docker.  I believe this change to the docker-config will be beneficial and increase accessibility, whereas retaining the current behavior is confusing to those not alreasy familiar with burrow.  Reverting ff7f09bf06522932f6c02b1ea4e21a5d0c26b442 would defeat the purpose of this PR.

I think I may have misread this the first time around and missed that the logging config change is just for the docker logging config. That is OK by me.


Fixed Docker pull links/syntax

The docker pull syntax in the README no longer works. Fixed.
Also fixed the link to the Docker Hub project as the original one 404s.

Thanks!


environment setup

Adding datmo environment setup
Fixing the issue in the test python basic task run example, https://github.com/datmo/datmo/issues/170

Pull Request Test Coverage Report for Build 646

25 of 29 (86.21%)  changed or added relevant lines in 4 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.01%) to 87.607%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

datmo/cli/command/environment.py
7
11
63.64%

Totals

Change from base Build 641:
-0.01%

Covered Lines:
3365

Relevant Lines:
3841

💛  - Coveralls


No kinematics solver instantiated when called robot_state.setFromIK() after running demo.launch.py

Description
See Steps to reproduce.
Your environment

ROS Distro: Humble
OS Version: Ubuntu 22.04
Binary build
2.5.5-1jammy

Steps to reproduce

Setup a new robot from urdf using Setup Assistant. I have set ik solver to KDLPlugin.
Run demo.launch.py under the package generated by Setup Assistant
In another cpp node:

Get MoveGroupInterface:
        node_for_move_group(std::make_shared<rclcpp::Node>("node_for_move_group")),
        move_group_interface(node_for_move_group, this->group_name),

Get RobotState and setFromIK():
        auto kinematic_state = *(this->move_group_interface.getCurrentState());
        bool found_ik = kinematic_state.setFromIK(this->joint_model_group, to, 10);

The full code is here: https://github.com/julyfun/fast_control/blob/c4eb5653791bcce04657a497453795800ce8895d/ik/src/moveit.cpp#L965
Expected behaviour
Get the IK result in kinematic_state
Backtrace or Console output
The Ik failed with:
[ik_moveit_exe-1] [ERROR] [1723098198.752732000] [moveit_robot_state.robot_state]: No kinematics solver instantiated for group 'left_dual2'

No other error or warning.

You need to ensure that your other cpp node also gets the kinematics parameters. Probably there is another warning complaining about missing kinematics parameters.