Charm waiting "Container is not ready" stuck forever

Versions
Microk8s: snap 1.24/stable (v1.24.16)
Juju: Controller 2.9.43 / CLI 2.9.44-ubuntu-amd64
resource-dispatcher: charm edge rev 78
Reproduce
Following https://discourse.charmhub.io/t/get-started-with-charmed-mlflow-v2-and-charmed-kubeflow/10782#heading--deploy-mlflow
juju deploy resource-dispatcher --channel edge --trust

juju relate mlflow-server:secrets resource-dispatcher:secrets
juju relate mlflow-server:pod-defaults resource-dispatcher:pod-defaults

microk8s.kubectl label ns admin user.kubeflow.org/enabled="true"
microk8s.kubectl label ns gustavosr98 user.kubeflow.org/enabled="true"

Logs
Juju
$ juju status --relations
juju status --relations
Model     Controller          Cloud/Region        Version  SLA          Timestamp
kubeflow  microk8s-localhost  microk8s/localhost  2.9.43   unsupported  19:35:14Z

SAAS                Status  Store               URL
grafana-dashboards  active  microk8s-localhost  admin/cos.grafana-dashboards
prometheus-scrape   active  microk8s-localhost  admin/cos.prometheus-scrape

App                        Version                  Status   Scale  Charm                    Channel         Rev  Address         Exposed  Message
admission-webhook          res:oci-image@2d74d1b    active       1  admission-webhook        1.7/stable      205  <IP_ADDRESS>   no
argo-controller            res:oci-image@669ebd5    active       1  argo-controller          3.3/stable      236                  no
argo-server                res:oci-image@576d038    active       1  argo-server              3.3/stable      185                  no
dex-auth                                            active       1  dex-auth                 2.31/stable     224  <IP_ADDRESS>  no
istio-ingressgateway                                active       1  istio-gateway            1.16/stable     551  <IP_ADDRESS>   no
istio-pilot                                         active       1  istio-pilot              1.16/stable     551  <IP_ADDRESS>   no
jupyter-controller         res:oci-image@1167186    active       1  jupyter-controller       1.7/stable      607                  no
jupyter-ui                                          active       1  jupyter-ui               1.7/stable      534  <IP_ADDRESS>  no
katib-controller           res:oci-image@111495a    active       1  katib-controller         0.15/stable     282  <IP_ADDRESS>  no
katib-db                   8.0.32-0ubuntu<IP_ADDRESS>  active       1  mysql-k8s                8.0/stable       75  <IP_ADDRESS>   no       Primary
katib-db-manager                                    waiting      1  katib-db-manager         0.15/stable     253  <IP_ADDRESS>  no       installing agent
katib-ui                                            active       1  katib-ui                 0.15/stable     267  <IP_ADDRESS>  no
kfp-api                                             active       1  kfp-api                  2.0/stable      413  <IP_ADDRESS>   no
kfp-db                     8.0.32-0ubuntu<IP_ADDRESS>  active       1  mysql-k8s                8.0/stable       75  <IP_ADDRESS>  no       Primary
kfp-persistence            res:oci-image@516e6b8    active       1  kfp-persistence          2.0/stable      407                  no
kfp-profile-controller     res:oci-image@03ace9b    active       1  kfp-profile-controller   2.0/stable      388  <IP_ADDRESS>  no
kfp-schedwf                res:oci-image@90ddd63    active       1  kfp-schedwf              2.0/stable      424                  no
kfp-ui                     res:oci-image@ae72602    active       1  kfp-ui                   2.0/stable      412  <IP_ADDRESS>  no
kfp-viewer                 res:oci-image@fcfe0d8    active       1  kfp-viewer               2.0/stable      424                  no
kfp-viz                    res:oci-image@3de6f3c    active       1  kfp-viz                  2.0/stable      394  <IP_ADDRESS>  no
knative-eventing                                    active       1  knative-eventing         1.8/stable      224  <IP_ADDRESS>  no
knative-operator                                    active       1  knative-operator         1.8/stable      199  <IP_ADDRESS>   no
knative-serving                                     active       1  knative-serving          1.8/stable      224  <IP_ADDRESS>  no
kserve-controller                                   active       1  kserve-controller        0.10/stable     267  <IP_ADDRESS>  no
kubeflow-dashboard                                  active       1  kubeflow-dashboard       1.7/stable      307  <IP_ADDRESS>   no
kubeflow-profiles                                   active       1  kubeflow-profiles        1.7/stable      269  <IP_ADDRESS>   no
kubeflow-roles                                      active       1  kubeflow-roles           1.7/stable      113  <IP_ADDRESS>   no
kubeflow-volumes           res:oci-image@d261609    active       1  kubeflow-volumes         1.7/stable      178  <IP_ADDRESS>   no
metacontroller-operator                             active       1  metacontroller-operator  2.0/stable      117  <IP_ADDRESS>  no
minio                      res:oci-image@1755999    active       1  minio                    ckf-1.7/stable  186  <IP_ADDRESS>  no
mlflow-minio               res:oci-image@1755999    active       1  minio                    ckf-1.7/edge    186  <IP_ADDRESS>  no
mlflow-mysql               8.0.32-0ubuntu<IP_ADDRESS>  active       1  mysql-k8s                8.0/stable       75  <IP_ADDRESS>  no       Primary
mlflow-server                                       waiting      1  mlflow-server            latest/edge     346  <IP_ADDRESS>  no       installing agent
oidc-gatekeeper            res:oci-image@6b720b8    active       1  oidc-gatekeeper          ckf-1.7/stable  176  <IP_ADDRESS>  no
postgresql-k8s             14.7                     waiting      1  postgresql-k8s           14/stable        73  <IP_ADDRESS>   no       installing agent
resource-dispatcher                                 waiting      1  resource-dispatcher      edge             78  <IP_ADDRESS>  no       installing agent
seldon-controller-manager                           active       1  seldon-core              1.15/stable     354  <IP_ADDRESS>   no
tensorboard-controller     res:oci-image@c52f7c2    active       1  tensorboard-controller   1.7/stable      156  <IP_ADDRESS>  no
tensorboards-web-app       res:oci-image@929f55b    active       1  tensorboards-web-app     1.7/stable      158  <IP_ADDRESS>   no
training-operator                                   active       1  training-operator        1.6/stable      190  <IP_ADDRESS>  no

Unit                          Workload  Agent  Address       Ports              Message
admission-webhook/0*          active    idle   <IP_ADDRESS>  4443/TCP
argo-controller/0*            active    idle   <IP_ADDRESS>
argo-server/0*                active    idle   <IP_ADDRESS>   2746/TCP
dex-auth/0*                   active    idle   <IP_ADDRESS>
istio-ingressgateway/0*       active    idle   <IP_ADDRESS>
istio-pilot/0*                active    idle   <IP_ADDRESS>
jupyter-controller/0*         active    idle   <IP_ADDRESS>
jupyter-ui/0*                 active    idle   <IP_ADDRESS>
katib-controller/0*           active    idle   <IP_ADDRESS>   443/TCP,8080/TCP
katib-db-manager/0*           error     idle   <IP_ADDRESS>                     hook failed: "update-status"
katib-db/0*                   active    idle   <IP_ADDRESS>                     Primary
katib-ui/0*                   active    idle   <IP_ADDRESS>
kfp-api/0*                    active    idle   <IP_ADDRESS>
kfp-db/0*                     active    idle   <IP_ADDRESS>                      Primary
kfp-persistence/0*            active    idle   <IP_ADDRESS>
kfp-profile-controller/0*     active    idle   <IP_ADDRESS>  80/TCP
kfp-schedwf/0*                active    idle   <IP_ADDRESS>
kfp-ui/0*                     active    idle   <IP_ADDRESS>  3000/TCP
kfp-viewer/0*                 active    idle   <IP_ADDRESS>
kfp-viz/0*                    active    idle   <IP_ADDRESS>   8888/TCP
knative-eventing/0*           active    idle   <IP_ADDRESS>
knative-operator/0*           active    idle   <IP_ADDRESS>
knative-serving/0*            active    idle   <IP_ADDRESS>
kserve-controller/0*          active    idle   <IP_ADDRESS>
kubeflow-dashboard/0*         active    idle   <IP_ADDRESS>
kubeflow-profiles/0*          active    idle   <IP_ADDRESS>
kubeflow-roles/0*             active    idle   <IP_ADDRESS>
kubeflow-volumes/0*           active    idle   <IP_ADDRESS>  5000/TCP
metacontroller-operator/0*    active    idle   <IP_ADDRESS>
minio/0*                      active    idle   <IP_ADDRESS>  9000/TCP,9001/TCP
mlflow-minio/0*               active    idle   <IP_ADDRESS>  9000/TCP,9001/TCP
mlflow-mysql/0*               active    idle   <IP_ADDRESS>                     Primary
mlflow-server/0*              waiting   idle   <IP_ADDRESS>                     List of <ops.model.Relation secrets:45> versions not found for apps: resource-dispatcher
oidc-gatekeeper/2*            active    idle   <IP_ADDRESS>  8080/TCP
postgresql-k8s/0*             waiting   idle   <IP_ADDRESS>                     awaiting for cluster to start
resource-dispatcher/0*        waiting   idle   <IP_ADDRESS>                       Container is not ready
seldon-controller-manager/0*  active    idle   <IP_ADDRESS>
tensorboard-controller/0*     active    idle   <IP_ADDRESS>   9443/TCP
tensorboards-web-app/0*       active    idle   <IP_ADDRESS>   5000/TCP
training-operator/0*          active    idle   <IP_ADDRESS>

Relation provider                            Requirer                               Interface           Type     Message
argo-controller:grafana-dashboard            grafana-dashboards:grafana-dashboard   grafana_dashboard   regular
argo-controller:metrics-endpoint             prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
dex-auth:metrics-endpoint                    prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
istio-pilot:gateway-info                     kserve-controller:ingress-gateway      istio-gateway-info  regular
istio-pilot:gateway-info                     tensorboard-controller:gateway-info    istio-gateway-info  regular
istio-pilot:ingress                          dex-auth:ingress                       ingress             regular
istio-pilot:ingress                          jupyter-ui:ingress                     ingress             regular
istio-pilot:ingress                          katib-ui:ingress                       ingress             regular
istio-pilot:ingress                          kfp-ui:ingress                         ingress             regular
istio-pilot:ingress                          kubeflow-dashboard:ingress             ingress             regular
istio-pilot:ingress                          kubeflow-volumes:ingress               ingress             regular
istio-pilot:ingress                          oidc-gatekeeper:ingress                ingress             regular
istio-pilot:ingress                          tensorboards-web-app:ingress           ingress             regular
istio-pilot:ingress-auth                     oidc-gatekeeper:ingress-auth           ingress-auth        regular
istio-pilot:istio-pilot                      istio-ingressgateway:istio-pilot       k8s-service         regular
jupyter-controller:grafana-dashboard         grafana-dashboards:grafana-dashboard   grafana_dashboard   regular
jupyter-controller:metrics-endpoint          prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
katib-controller:metrics-endpoint            prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
katib-db:database                            katib-db-manager:relational-db         mysql_client        regular
katib-db:database-peers                      katib-db:database-peers                mysql_peers         peer
kfp-api:kfp-api                              kfp-persistence:kfp-api                k8s-service         regular
kfp-api:kfp-api                              kfp-ui:kfp-api                         k8s-service         regular
kfp-api:metrics-endpoint                     prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
kfp-db:database                              kfp-api:relational-db                  mysql_client        regular
kfp-db:database-peers                        kfp-db:database-peers                  mysql_peers         peer
kfp-viz:kfp-viz                              kfp-api:kfp-viz                        k8s-service         regular
kubeflow-profiles:kubeflow-profiles          kubeflow-dashboard:kubeflow-profiles   k8s-service         regular
metacontroller-operator:metrics-endpoint     prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
minio:metrics-endpoint                       prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
minio:object-storage                         argo-controller:object-storage         object-storage      regular
minio:object-storage                         kfp-api:object-storage                 object-storage      regular
minio:object-storage                         kfp-profile-controller:object-storage  object-storage      regular
minio:object-storage                         kfp-ui:object-storage                  object-storage      regular
mlflow-minio:object-storage                  mlflow-server:object-storage           object-storage      regular
mlflow-mysql:database                        mlflow-server:relational-db            mysql_client        regular
mlflow-mysql:database-peers                  mlflow-mysql:database-peers            mysql_peers         peer
mlflow-server:pod-defaults                   resource-dispatcher:pod-defaults       pod-defaults        regular
mlflow-server:secrets                        resource-dispatcher:secrets            secrets             regular
oidc-gatekeeper:client-secret                oidc-gatekeeper:client-secret          client-secret       peer
oidc-gatekeeper:oidc-client                  dex-auth:oidc-client                   oidc-client         regular
postgresql-k8s:database-peers                postgresql-k8s:database-peers          postgresql_peers    peer
postgresql-k8s:restart                       postgresql-k8s:restart                 rolling_op          peer
seldon-controller-manager:grafana-dashboard  grafana-dashboards:grafana-dashboard   grafana_dashboard   regular
seldon-controller-manager:metrics-endpoint   prometheus-scrape:metrics-endpoint     prometheus_scrape   regular
training-operator:metrics-endpoint           prometheus-scrape:metrics-endpoint     prometheus_scrape   regular

$ juju show-status-log resource-dispatcher/0
Time                   Type       Status       Message
02 Aug 2023 18:37:13Z  workload   waiting      agent initializing
02 Aug 2023 18:37:16Z  workload   maintenance  installing charm software
02 Aug 2023 18:37:16Z  juju-unit  executing    running install hook
02 Aug 2023 18:37:18Z  workload   maintenance  Creating K8S resources
02 Aug 2023 18:37:19Z  workload   waiting      K8s resources created. Waiting for charm to be active
02 Aug 2023 18:37:19Z  juju-unit  executing    running secrets-relation-created hook
02 Aug 2023 18:37:20Z  juju-unit  executing    running leader-elected hook
02 Aug 2023 18:37:21Z  juju-unit  executing    running config-changed hook
02 Aug 2023 18:37:23Z  juju-unit  executing    running start hook
02 Aug 2023 18:37:24Z  juju-unit  executing    running secrets-relation-changed hook
02 Aug 2023 18:37:25Z  juju-unit  executing    running secrets-relation-joined hook for mlflow-server/0
02 Aug 2023 18:37:26Z  juju-unit  executing    running secrets-relation-changed hook for mlflow-server/0
02 Aug 2023 18:37:28Z  juju-unit  idle
02 Aug 2023 18:37:41Z  juju-unit  executing    running pod-defaults-relation-created hook
02 Aug 2023 18:37:42Z  juju-unit  executing    running pod-defaults-relation-joined hook for mlflow-server/0
02 Aug 2023 18:37:43Z  juju-unit  executing    running pod-defaults-relation-changed hook for mlflow-server/0
02 Aug 2023 18:37:44Z  juju-unit  idle
02 Aug 2023 18:37:51Z  juju-unit  executing    running resource-dispatcher-pebble-ready hook
02 Aug 2023 18:38:27Z  juju-unit  idle
02 Aug 2023 18:38:27Z  workload   waiting      Container is not ready

$ date
Wed Aug  2 19:40:44 UTC 2023

K8s
$ microk8s.kubectl get pods -n kubeflow | grep disp
resource-dispatcher-0                           2/2     Running   0               58m

microk8s.kubectl logs -n kubeflow resource-dispatcher-0
Defaulted container "charm" out of: charm, resource-dispatcher, charm-init (init)
2023-08-02T18:37:13.428Z [pebble] HTTP API server listening on ":38812".
2023-08-02T18:37:13.429Z [pebble] Started daemon.
2023-08-02T18:37:13.431Z [pebble] POST /v1/services 2.029056ms 202
2023-08-02T18:37:13.431Z [pebble] Started default services with change 1.
2023-08-02T18:37:13.433Z [pebble] Service "container-agent" starting: /charm/bin/containeragent unit --data-dir /var/lib/juju --append-env "PATH=$PATH:/charm/bin" --show-log --charm-modified-version 0
2023-08-02T18:37:13.507Z [container-agent] 2023-08-02 18:37:13 INFO juju.cmd supercommand.go:56 running containerAgent [2.9.43 3cb3f8beac4a0b05e10bdfb8014f5666118a269d gc go1.20.4]
2023-08-02T18:37:13.507Z [container-agent] starting containeragent unit command
2023-08-02T18:37:13.507Z [container-agent] containeragent unit "unit-resource-dispatcher-0" start (2.9.43 [gc])
2023-08-02T18:37:13.507Z [container-agent] 2023-08-02 18:37:13 INFO juju.cmd.containeragent.unit runner.go:556 start "unit"
2023-08-02T18:37:13.507Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.upgradesteps worker.go:60 upgrade steps for 2.9.43 have already been run.
2023-08-02T18:37:13.508Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.probehttpserver server.go:157 starting http server on [::]:65301
2023-08-02T18:37:13.542Z [container-agent] 2023-08-02 18:37:13 INFO juju.api apiclient.go:687 connection established to "wss://controller-service.controller-microk8s-localhost.svc.cluster.local:17070/model/ae7a86b2-19d4-483d-8ccc-2bcd21bdad79/api"
2023-08-02T18:37:13.546Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.apicaller connect.go:163 [ae7a86] "unit-resource-dispatcher-0" successfully connected to "controller-service.controller-microk8s-localhost.svc.cluster.local:17070"
2023-08-02T18:37:13.569Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.migrationminion worker.go:142 migration phase is now: NONE
2023-08-02T18:37:13.570Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.logger logger.go:120 logger worker started
2023-08-02T18:37:13.572Z [container-agent] 2023-08-02 18:37:13 WARNING juju.worker.proxyupdater proxyupdater.go:282 unable to set snap core settings [proxy.http= proxy.https= proxy.store=]: exec: "snap": executable file not found in $PATH, output: ""
2023-08-02T18:37:13.589Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.leadership tracker.go:194 resource-dispatcher/0 promoted to leadership of resource-dispatcher
2023-08-02T18:37:13.596Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.caasupgrader upgrader.go:113 abort check blocked until version event received
2023-08-02T18:37:13.596Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.caasupgrader upgrader.go:119 unblocking abort check
2023-08-02T18:37:13.606Z [container-agent] 2023-08-02 18:37:13 INFO juju.agent.tools symlinks.go:20 ensure jujuc symlinks in /var/lib/juju/tools/unit-resource-dispatcher-0
2023-08-02T18:37:13.620Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.uniter uniter.go:326 unit "resource-dispatcher/0" started
2023-08-02T18:37:13.621Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.uniter uniter.go:634 resuming charm install
2023-08-02T18:37:13.623Z [container-agent] 2023-08-02 18:37:13 INFO juju.worker.uniter.charm bundles.go:81 downloading ch:amd64/focal/resource-dispatcher-78 from API server
2023-08-02T18:37:13.623Z [container-agent] 2023-08-02 18:37:13 INFO juju.downloader download.go:110 downloading from ch:amd64/focal/resource-dispatcher-78
2023-08-02T18:37:13.731Z [container-agent] 2023-08-02 18:37:13 INFO juju.downloader download.go:93 download complete ("ch:amd64/focal/resource-dispatcher-78")
2023-08-02T18:37:13.795Z [container-agent] 2023-08-02 18:37:13 INFO juju.downloader download.go:173 download verified ("ch:amd64/focal/resource-dispatcher-78")
2023-08-02T18:37:16.198Z [container-agent] 2023-08-02 18:37:16 INFO juju.worker.uniter uniter.go:344 hooks are retried true
2023-08-02T18:37:16.266Z [container-agent] 2023-08-02 18:37:16 INFO juju.worker.uniter resolver.go:159 found queued "install" hook
2023-08-02T18:37:17.498Z [container-agent] 2023-08-02 18:37:17 INFO juju-log Running legacy hooks/install.
2023-08-02T18:37:18.764Z [container-agent] 2023-08-02 18:37:18 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/apis/apiextensions.k8s.io/v1/customresourcedefinitions "HTTP/1.1 200 OK"
2023-08-02T18:37:18.946Z [container-agent] 2023-08-02 18:37:18 INFO juju-log Rendering manifests
2023-08-02T18:37:19.035Z [container-agent] 2023-08-02 18:37:19 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/apis/metacontroller.k8s.io/v1alpha1/decoratorcontrollers/kubeflow-resource-dispatcher-controller?fieldManager=lightkube "HTTP/1.1 201 Created"
2023-08-02T18:37:19.066Z [container-agent] 2023-08-02 18:37:19 INFO juju-log Reconcile completed successfully
2023-08-02T18:37:19.194Z [container-agent] 2023-08-02 18:37:19 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:37:19.277Z [container-agent] 2023-08-02 18:37:19 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:37:19.346Z [container-agent] 2023-08-02 18:37:19 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T18:37:19.677Z [container-agent] 2023-08-02 18:37:19 INFO juju.worker.uniter.operation runhook.go:159 ran "install" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:20.703Z [container-agent] 2023-08-02 18:37:20 INFO juju.worker.uniter.operation runhook.go:159 ran "secrets-relation-created" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:20.761Z [container-agent] 2023-08-02 18:37:20 INFO juju.worker.uniter resolver.go:159 found queued "leader-elected" hook
2023-08-02T18:37:21.692Z [container-agent] 2023-08-02 18:37:21 INFO juju.worker.uniter.operation runhook.go:159 ran "leader-elected" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:22.477Z [container-agent] 2023-08-02 18:37:22 INFO juju-log Event <ConfigChangedEvent via ResourceDispatcherOperator/on/config_changed[10]> stopped early with message: Container is not ready
2023-08-02T18:37:22.579Z [container-agent] 2023-08-02 18:37:22 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:37:22.707Z [container-agent] 2023-08-02 18:37:22 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:37:22.741Z [container-agent] 2023-08-02 18:37:22 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T18:37:23.026Z [container-agent] 2023-08-02 18:37:23 INFO juju.worker.uniter.operation runhook.go:159 ran "config-changed" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:23.069Z [container-agent] 2023-08-02 18:37:23 INFO juju.worker.uniter resolver.go:159 found queued "start" hook
2023-08-02T18:37:23.432Z [pebble] Check "readiness" failure 1 (threshold 3): received non-20x status code 418
2023-08-02T18:37:23.824Z [container-agent] 2023-08-02 18:37:23 INFO juju-log Running legacy hooks/start.
2023-08-02T18:37:24.849Z [container-agent] 2023-08-02 18:37:24 INFO juju.worker.uniter.operation runhook.go:159 ran "start" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:25.606Z [container-agent] 2023-08-02 18:37:25 INFO juju-log secrets:45: Event <RelationChangedEvent via ResourceDispatcherOperator/on/secrets_relation_changed[16]> stopped early with message: Container is not ready
2023-08-02T18:37:25.868Z [container-agent] 2023-08-02 18:37:25 INFO juju.worker.uniter.operation runhook.go:159 ran "secrets-relation-changed" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:26.904Z [container-agent] 2023-08-02 18:37:26 INFO juju.worker.uniter.operation runhook.go:159 ran "secrets-relation-joined" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:27.804Z [container-agent] 2023-08-02 18:37:27 INFO juju-log secrets:45: Event <RelationChangedEvent via ResourceDispatcherOperator/on/secrets_relation_changed[22]> stopped early with message: Container is not ready
2023-08-02T18:37:28.073Z [container-agent] 2023-08-02 18:37:28 INFO juju.worker.uniter.operation runhook.go:159 ran "secrets-relation-changed" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:42.658Z [container-agent] 2023-08-02 18:37:42 INFO juju.worker.uniter.operation runhook.go:159 ran "pod-defaults-relation-created" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:43.732Z [container-agent] 2023-08-02 18:37:43 INFO juju.worker.uniter.operation runhook.go:159 ran "pod-defaults-relation-joined" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:44.474Z [container-agent] 2023-08-02 18:37:44 INFO juju-log pod-defaults:46: Event <RelationChangedEvent via ResourceDispatcherOperator/on/pod_defaults_relation_changed[31]> stopped early with message: Container is not ready
2023-08-02T18:37:44.740Z [container-agent] 2023-08-02 18:37:44 INFO juju.worker.uniter.operation runhook.go:159 ran "pod-defaults-relation-changed" hook (via hook dispatching script: dispatch)
2023-08-02T18:37:52.029Z [container-agent] 2023-08-02 18:37:52 INFO juju.worker.uniter.operation runhook.go:159 ran "resource-dispatcher-pebble-ready" hook (via hook dispatching script: dispatch)
2023-08-02T18:41:48.235Z [container-agent] 2023-08-02 18:41:48 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:41:48.308Z [container-agent] 2023-08-02 18:41:48 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:41:48.338Z [container-agent] 2023-08-02 18:41:48 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T18:41:48.600Z [container-agent] 2023-08-02 18:41:48 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T18:47:39.981Z [container-agent] 2023-08-02 18:47:39 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:47:40.050Z [container-agent] 2023-08-02 18:47:40 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:47:40.078Z [container-agent] 2023-08-02 18:47:40 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T18:47:40.340Z [container-agent] 2023-08-02 18:47:40 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T18:52:40.260Z [container-agent] 2023-08-02 18:52:40 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:52:40.332Z [container-agent] 2023-08-02 18:52:40 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:52:40.363Z [container-agent] 2023-08-02 18:52:40 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T18:52:40.624Z [container-agent] 2023-08-02 18:52:40 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T18:58:14.741Z [container-agent] 2023-08-02 18:58:14 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:58:14.822Z [container-agent] 2023-08-02 18:58:14 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T18:58:14.857Z [container-agent] 2023-08-02 18:58:14 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T18:58:15.137Z [container-agent] 2023-08-02 18:58:15 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:03:11.479Z [container-agent] 2023-08-02 19:03:11 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:03:11.549Z [container-agent] 2023-08-02 19:03:11 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:03:11.578Z [container-agent] 2023-08-02 19:03:11 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:03:11.834Z [container-agent] 2023-08-02 19:03:11 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:07:32.602Z [container-agent] 2023-08-02 19:07:32 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:07:32.671Z [container-agent] 2023-08-02 19:07:32 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:07:32.699Z [container-agent] 2023-08-02 19:07:32 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:07:32.958Z [container-agent] 2023-08-02 19:07:32 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:11:48.210Z [container-agent] 2023-08-02 19:11:48 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:11:48.277Z [container-agent] 2023-08-02 19:11:48 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:11:48.306Z [container-agent] 2023-08-02 19:11:48 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:11:48.572Z [container-agent] 2023-08-02 19:11:48 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:17:29.177Z [container-agent] 2023-08-02 19:17:29 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:17:29.254Z [container-agent] 2023-08-02 19:17:29 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:17:29.286Z [container-agent] 2023-08-02 19:17:29 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:17:29.558Z [container-agent] 2023-08-02 19:17:29 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:21:38.074Z [container-agent] 2023-08-02 19:21:38 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:21:38.146Z [container-agent] 2023-08-02 19:21:38 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:21:38.175Z [container-agent] 2023-08-02 19:21:38 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:21:38.445Z [container-agent] 2023-08-02 19:21:38 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:26:19.881Z [container-agent] 2023-08-02 19:26:19 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:26:19.953Z [container-agent] 2023-08-02 19:26:19 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:26:19.982Z [container-agent] 2023-08-02 19:26:19 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:26:20.238Z [container-agent] 2023-08-02 19:26:20 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:30:34.167Z [container-agent] 2023-08-02 19:30:34 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:30:34.237Z [container-agent] 2023-08-02 19:30:34 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:30:34.271Z [container-agent] 2023-08-02 19:30:34 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:30:34.551Z [container-agent] 2023-08-02 19:30:34 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)
2023-08-02T19:35:28.253Z [container-agent] 2023-08-02 19:35:28 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:35:28.322Z [container-agent] 2023-08-02 19:35:28 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/kubeflow/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-02T19:35:28.354Z [container-agent] 2023-08-02 19:35:28 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-02T19:35:28.618Z [container-agent] 2023-08-02 19:35:28 INFO juju.worker.uniter.operation runhook.go:159 ran "update-status" hook (via hook dispatching script: dispatch)

Seems a workaround for it to remove the application, re-deploy and re-add relations
juju remove-application resource-dispatcher

juju deploy resource-dispatcher --channel edge --trust

juju relate mlflow-server:secrets resource-dispatcher:secrets
juju relate mlflow-server:pod-defaults resource-dispatcher:pod-defaults

@gustavosr98 I could not reproduce your issue, but I got similar results.
After deploying resource-dispatcher:
juju deploy resource-dispatcher --channel edge --trust

I waited until it went into state you describe 'Container is not ready, only after that I added the required mlflow-server:*relations andresource-dispatcher` came up successfully.
This is not expected behaviour.
Could you please confirm same behaviour? I.e. successful deployment of resource-dispatcher if relations are added after it is goes into Container is not ready state.
It is very tricky to test, because once resource-dispatcher successfully deployed once, it always comes up afterwards, regardless when relations are added.

Just re-run tests exactly as originally outlined by @gustavosr98  and could not reproduce the issue.

Logs for resource-dispatcher in Container is not ready:
$ microk8s.kubectl -n test1 logs resource-dispatcher-0
Defaulted container "charm" out of: charm, resource-dispatcher, charm-init (init)
2023-08-16T21:37:09.708Z [pebble] HTTP API server listening on ":38812".
2023-08-16T21:37:09.708Z [pebble] Started daemon.
2023-08-16T21:37:09.714Z [pebble] POST /v1/services 5.706092ms 202
2023-08-16T21:37:09.715Z [pebble] Started default services with change 1.
2023-08-16T21:37:09.721Z [pebble] Service "container-agent" starting: /charm/bin/containeragent unit --data-dir /var/lib/juju --append-env "PATH=$PATH:/charm/bin" --show-log --charm-modified-version 0
2023-08-16T21:37:09.761Z [container-agent] 2023-08-16 21:37:09 INFO juju.cmd supercommand.go:56 running containerAgent [2.9.44 02d498631e196f2a37f9b7c3b5c31bdcb1dad333 gc go1.20.5]
2023-08-16T21:37:09.761Z [container-agent] starting containeragent unit command
2023-08-16T21:37:09.761Z [container-agent] containeragent unit "unit-resource-dispatcher-0" start (2.9.44 [gc])
2023-08-16T21:37:09.761Z [container-agent] 2023-08-16 21:37:09 INFO juju.cmd.containeragent.unit runner.go:556 start "unit"
2023-08-16T21:37:09.761Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.upgradesteps worker.go:60 upgrade steps for 2.9.44 have already been run.
2023-08-16T21:37:09.762Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.probehttpserver server.go:157 starting http server on [::]:65301
2023-08-16T21:37:09.787Z [container-agent] 2023-08-16 21:37:09 INFO juju.api apiclient.go:1054 cannot resolve "controller-service.controller-uk8s.svc.cluster.local": lookup controller-service.controller-uk8s.svc.cluster.local: operation was canceled
2023-08-16T21:37:09.787Z [container-agent] 2023-08-16 21:37:09 INFO juju.api apiclient.go:687 connection established to "wss://<IP_ADDRESS>:17070/model/5027f823-e089-4fc5-87c4-0dd3e6361a92/api"
2023-08-16T21:37:09.792Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.apicaller connect.go:163 [5027f8] "unit-resource-dispatcher-0" successfully connected to "<IP_ADDRESS>:17070"
2023-08-16T21:37:09.815Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.migrationminion worker.go:142 migration phase is now: NONE
2023-08-16T21:37:09.816Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.logger logger.go:120 logger worker started
2023-08-16T21:37:09.821Z [container-agent] 2023-08-16 21:37:09 WARNING juju.worker.proxyupdater proxyupdater.go:282 unable to set snap core settings [proxy.http= proxy.https= proxy.store=]: exec: "snap": executable file not found in $PATH, output: ""
2023-08-16T21:37:09.847Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.leadership tracker.go:194 resource-dispatcher/0 promoted to leadership of resource-dispatcher
2023-08-16T21:37:09.850Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.caasupgrader upgrader.go:113 abort check blocked until version event received
2023-08-16T21:37:09.850Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.caasupgrader upgrader.go:119 unblocking abort check
2023-08-16T21:37:09.866Z [container-agent] 2023-08-16 21:37:09 INFO juju.agent.tools symlinks.go:20 ensure jujuc symlinks in /var/lib/juju/tools/unit-resource-dispatcher-0
2023-08-16T21:37:09.885Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.uniter uniter.go:326 unit "resource-dispatcher/0" started
2023-08-16T21:37:09.890Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.uniter uniter.go:642 resuming charm install
2023-08-16T21:37:09.893Z [container-agent] 2023-08-16 21:37:09 INFO juju.worker.uniter.charm bundles.go:81 downloading ch:amd64/focal/resource-dispatcher-78 from API server
2023-08-16T21:37:09.893Z [container-agent] 2023-08-16 21:37:09 INFO juju.downloader download.go:110 downloading from ch:amd64/focal/resource-dispatcher-78
2023-08-16T21:37:10.011Z [container-agent] 2023-08-16 21:37:10 INFO juju.downloader download.go:93 download complete ("ch:amd64/focal/resource-dispatcher-78")
2023-08-16T21:37:10.054Z [container-agent] 2023-08-16 21:37:10 INFO juju.downloader download.go:173 download verified ("ch:amd64/focal/resource-dispatcher-78")
2023-08-16T21:37:18.400Z [container-agent] 2023-08-16 21:37:18 INFO juju.worker.uniter uniter.go:352 hooks are retried true
2023-08-16T21:37:18.480Z [container-agent] 2023-08-16 21:37:18 INFO juju.worker.uniter resolver.go:159 found queued "install" hook
2023-08-16T21:37:19.712Z [pebble] Check "readiness" failure 1 (threshold 3): received non-20x status code 418
2023-08-16T21:37:19.753Z [container-agent] 2023-08-16 21:37:19 INFO juju-log Running legacy hooks/install.
2023-08-16T21:37:20.734Z [container-agent] 2023-08-16 21:37:20 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/apis/apiextensions.k8s.io/v1/customresourcedefinitions "HTTP/1.1 200 OK"
2023-08-16T21:37:20.792Z [container-agent] 2023-08-16 21:37:20 INFO juju-log Rendering manifests
2023-08-16T21:37:20.904Z [container-agent] 2023-08-16 21:37:20 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/apis/metacontroller.k8s.io/v1alpha1/decoratorcontrollers/kubeflow-resource-dispatcher-controller?fieldManager=lightkube "HTTP/1.1 201 Created"
2023-08-16T21:37:20.951Z [container-agent] 2023-08-16 21:37:20 INFO juju-log Reconcile completed successfully
2023-08-16T21:37:21.112Z [container-agent] 2023-08-16 21:37:21 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/test1/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-16T21:37:21.219Z [container-agent] 2023-08-16 21:37:21 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/test1/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-16T21:37:21.269Z [container-agent] 2023-08-16 21:37:21 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-16T21:37:21.589Z [container-agent] 2023-08-16 21:37:21 INFO juju.worker.uniter.operation runhook.go:159 ran "install" hook (via hook dispatching script: dispatch)
2023-08-16T21:37:21.658Z [container-agent] 2023-08-16 21:37:21 INFO juju.worker.uniter resolver.go:159 found queued "leader-elected" hook
2023-08-16T21:37:22.619Z [container-agent] 2023-08-16 21:37:22 INFO juju.worker.uniter.operation runhook.go:159 ran "leader-elected" hook (via hook dispatching script: dispatch)
2023-08-16T21:37:23.423Z [container-agent] 2023-08-16 21:37:23 INFO juju-log Event <ConfigChangedEvent via ResourceDispatcherOperator/on/config_changed[7]> stopped early with message: Container is not ready
2023-08-16T21:37:23.555Z [container-agent] 2023-08-16 21:37:23 INFO juju-log HTTP Request: GET https://<IP_ADDRESS>/api/v1/namespaces/test1/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-16T21:37:23.663Z [container-agent] 2023-08-16 21:37:23 INFO juju-log HTTP Request: PATCH https://<IP_ADDRESS>/api/v1/namespaces/test1/services/resource-dispatcher "HTTP/1.1 200 OK"
2023-08-16T21:37:23.708Z [container-agent] 2023-08-16 21:37:23 INFO juju-log Kubernetes service 'resource-dispatcher' patched successfully
2023-08-16T21:37:24.009Z [container-agent] 2023-08-16 21:37:24 INFO juju.worker.uniter.operation runhook.go:159 ran "config-changed" hook (via hook dispatching script: dispatch)
2023-08-16T21:37:24.048Z [container-agent] 2023-08-16 21:37:24 INFO juju.worker.uniter resolver.go:159 found queued "start" hook
2023-08-16T21:37:24.691Z [container-agent] 2023-08-16 21:37:24 INFO juju-log Running legacy hooks/start.
2023-08-16T21:37:25.699Z [container-agent] 2023-08-16 21:37:25 INFO juju.worker.uniter.operation runhook.go:159 ran "start" hook (via hook dispatching script: dispatch)
2023-08-16T21:37:37.578Z [container-agent] 2023-08-16 21:37:37 INFO juju.worker.uniter.operation runhook.go:159 ran "resource-dispatcher-pebble-ready" hook (via hook dispatching script: dispatch)

Looks like service in resource-dispatcher container is not started when initially deployed. Or started and failed.
MInimal steps to reproduce (on clean microk8s cluser and Juju controller):
juju add-model test1
juju deploy metacontroller-operator --channel 2.0/stable --trust

Wait till metacontroller-operator is installed and in idle/active state and deploy resource-dispatcher:
juju deploy resource-dispatcher --channel edge --trust

The above should result in the following state:
Model  Controller  Cloud/Region        Version  SLA          Timestamp
test1  uk8s        microk8s/localhost  2.9.44   unsupported  21:38:12Z

App                      Version  Status   Scale  Charm                    Channel     Rev  Address         Exposed  Message
metacontroller-operator           active       1  metacontroller-operator  2.0/stable  117  <IP_ADDRESS>   no
resource-dispatcher               waiting      1  resource-dispatcher      edge         78  <IP_ADDRESS>  no       installing agent

Unit                        Workload  Agent  Address      Ports  Message
metacontroller-operator/0*  active    idle   <IP_ADDRESS>
resource-dispatcher/0*      waiting   idle   <IP_ADDRESS>         Container is not ready

Command python3 main.py for container based on resource-dispatcher-image is not running:
$ microk8s.kubectl -n test1 exec -c resource-dispatcher  resource-dispatcher-0 -- ps -ax
    PID TTY      STAT   TIME COMMAND
      1 ?        Ssl    0:00 /charm/bin/pebble run --create-dirs --hold --http :38813 --verbose
     16 ?        Rs     0:00 ps -ax

When properly started, command should be running:
$ microk8s.kubectl -n test1 exec -c resource-dispatcher  resource-dispatcher-0 -- ps -ax
    PID TTY      STAT   TIME COMMAND
      1 ?        Ssl    0:00 /charm/bin/pebble run --create-dirs --hold --http :38813 --verbose
     16 ?        S      0:00 python3 main.py --port 80 --label user.kubeflow.org/enabled
     17 ?        Rs     0:00 ps -ax
     ```

Candidate for fix in 1.8

Resolved in https://github.com/canonical/resource-dispatcher/pull/35


Native automatic mixed precision for fastai2

Native automatic mixed precision support (torch.cuda.amp) is finally merged:
https://pytorch.org/docs/master/amp.html
https://pytorch.org/docs/master/notes/amp_examples.html
Apex Amp has many known pain points (extension builds, forward/backward compatibilty, DataParallel support, flaky checkpointing, i don’t even know if it can be hacked to handle double backward/gradient penalty, others…). torch.cuda.amp fixes all these, the interface is more flexible and intuitive, and the tighter integration with pytorch brings more future optimizations into scope.
I think the torch.cuda.amp API is a good fit for a higher-level library like fastai because its style is more functional (as in, it doesn't statefully alter anything outside itself). The necessary torch.cuda.amp calls don't have silent/weird effects elsewhere.
If you want to talk about adding torch.cuda.amp to fastai, with an eye towards it becoming the future-proof source of mixed precision, message me on Pytorch slack anytime. I pinged you there as well but I’m not sure if you monitor it habitually.

Hi there! No we don't always monitor the PyTorch slack, so thanks for reaching out here!
The problem is that it was designed by basically altering every line of code of the base training loop, which is completely incompatible with the way fastai usually tweaks the training loop (we change the training loop via callbacks and always keep the same core), so I'm not sure we will actually be able to use it (the same way we were using the helper functions from apex but not actually apex).
I have to dig behind the front-end layer to see how it could fit with our callback way of doing things but we have a lot on our plates right now, so it won't be before a few weeks. Can we continue the discussion on the fastai forum? Closing this issue since we keep issues for bugs in the library only, features are usually discussed there (and we may find people able to help with the conversion).

Ah! I just got a crazy idea that would allow us to use the tweaked training loop! Will look at this over the weekend and report back here (note that his won't be for v1 in any case so we can leave the issue in the fastai repo closed)

Great!!  It should be in nightlies.  But FYI, unrelated to amp, torch.topk is broken with fp16 on master right now.  Fix is in flight (https://github.com/pytorch/pytorch/pull/35734, https://github.com/pytorch/pytorch/pull/35986) but topk is pretty common so i'd give master a week to stabilize.
If you want, I can describe the design in detail on slack.  You may find it's less invasive than you fear (certainly less than Apex Amp).  I can also describe the lower-level torch functions the documented API calls into, if those are more suitable for fastai's design.

should I still move this to the forum?

There is topic there already.
I have added the basic support in this commit, but it will need some additional work for some other callbacks like gradient clipping. I'll start testing it works as nicely as what we have next week.

Fantastic!  I looked over the code and my first question is:  why does it need to be so complex?  With the native integration, the model should not be cast to .half().  model params are FP32 and == params stepped by the optimizer, as with non-mixed-precision training.  There's no need to maintain master params distinct from the model params (which was an irritating, confusing, and brittle aspect of some earlier mixed precision formulations.  We're learning as we go...).
These
https://github.com/fastai/fastai2/commit/60d63c3e27fb8ea5cf1e8d105b862bceb8fd612d#diff-0477c8e3e5e8d3059dafd449dfd17fe1R157-R164
https://github.com/fastai/fastai2/commit/60d63c3e27fb8ea5cf1e8d105b862bceb8fd612d#diff-0477c8e3e5e8d3059dafd449dfd17fe1R179
(which look correct) are all you need to do in the training loop, and their effects are local to the body of each iteration (aside from scaler itself, which updates its internal scale over time).
You also need to construct the GradScaler instance once that the beginning of training (which you are).
Warning about something I did not see:
For bitwise accurate saving/restoring, you should include scaler.state_dict() and scaler.load_state_dict() alongside the usual model/optimizer state dict handling.
Still not sure what your preferred mode of communication is :P  Should I ship all this discussion to the forum?  Comment on the PR?  Continue here?

Thanks for your comments!
All that is before mixed_precision_one_batch is the current implementation of mixed precision which we won't remove until there has been a release of PyTorch and we have confirmed native mixed precision work. So the implementation of native mixed precision is just the altered one_batch function and the callback, you can ignore the rest of the callback.fp16 module.
We have not implemented any saving/restoring on the callbacks yet. We just rely on pickling the whole thing for now.
For communication, the preferred mode is the forum since that is where our community is and will see the whole thing (I mostly pinged you on the issue to let you know what I had done since I did not see you on the forum).

Moving to https://forums.fast.ai/t/automatic-mixed-precision-native-in-pytorch-nightly/67440/4.


Update key-to-did

As suggested in https://github.com/spruceid/didkit/pull/217#issuecomment-923955313

Update summary line
Add paragraphs to help text.
Use did:key by default.

Resulting output
Using --help is a little different from -h, with the structopt library that we are using here.
It may be possible to output different long-form text for -h than --help. For now it's the same, written using doc comments. The library generates a more expanded description of the options and flags for --help, while it is more compact for -h, as you can see in the following output samples.
More info: https://docs.rs/structopt/0.3.25/structopt/index.html#help-messages

$ didkit key-to-did -h
didkit-key-to-did 0.1.1
Output a DID for a given JWK according to the provided DID method name or pattern

Deterministically generate a DID from a public key JWK, for a DID method that support this functionality.

The DID method to use may be provided in the `method-pattern` argument. The default is `did:key`.

For DID methods that have multiple ways of representing a key, `method-pattern` is method-specific but typically is a
prefix, for example "pkh:tz" to generate a DID that begins with `did:pkh:tz`.

USAGE:
    didkit key-to-did [OPTIONS] <--key-path <key-path>|--jwk <jwk>|--ssh-agent> [method-pattern]

FLAGS:
    -h, --help         Prints help information
    -S, --ssh-agent    Request signature using SSH Agent
    -V, --version      Prints version information

OPTIONS:
    -j, --jwk <jwk>              WARNING: you should not use this through the CLI in a production environment, prefer
                                 its environment variable. [env: JWK]
    -k, --key-path <key-path>     [env: KEY_PATH=]

ARGS:
    <method-pattern>    DID method name or pattern. e.g. `key`, `tz`, or `pkh:tz` [default: key]

$ didkit key-to-did --help
didkit-key-to-did 0.1.1
Output a DID for a given JWK according to the provided DID method name or pattern

Deterministically generate a DID from a public key JWK, for a DID method that support this functionality.

The DID method to use may be provided in the `method-pattern` argument. The default is `did:key`.

For DID methods that have multiple ways of representing a key, `method-pattern` is method-specific but typically is a
prefix, for example "pkh:tz" to generate a DID that begins with `did:pkh:tz`.

USAGE:
    didkit key-to-did [OPTIONS] <--key-path <key-path>|--jwk <jwk>|--ssh-agent> [method-pattern]

FLAGS:
    -h, --help
            Prints help information

    -S, --ssh-agent
            Request signature using SSH Agent

    -V, --version
            Prints version information

OPTIONS:
    -j, --jwk <jwk>
            WARNING: you should not use this through the CLI in a production environment, prefer its environment
            variable. [env: JWK]
    -k, --key-path <key-path>
             [env: KEY_PATH=]

ARGS:
    <method-pattern>
            DID method name or pattern. e.g. `key`, `tz`, or `pkh:tz` [default: key]

The summary line appears in the top-level help text, as in the following.

$ didkit -h
didkit-cli 0.1.1

USAGE:
    didkit <SUBCOMMAND>

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

SUBCOMMANDS:
    did-auth                      Authenticate with a DID
    did-dereference               Dereference a DID URL to a resource
    did-resolve                   Resolve a DID to a DID Document
    generate-ed25519-key          Generate and output a Ed25519 keypair in JWK format
    help                          Prints this message or the help of the given subcommand(s)
    key-to-did                    Output a DID for a given JWK according to the provided DID method name or pattern
    key-to-verification-method    Output a verificationMethod DID URL for a JWK and DID method name/pattern
    ssh-pk-to-jwk                 Convert a SSH public key to a JWK
    to-rdf-urdna2015              Convert JSON-LD to URDNA2015-canonicalized RDF N-Quads
    vc-issue-credential           Issue Credential
    vc-issue-presentation         Issue Presentation
    vc-verify-credential          Verify Credential
    vc-verify-presentation        Verify Presentation

Rebasing and merging.


for 6.0

links the msvc runtime statically, eliminating the need for vcredist

I think we should bump a major version and recommend reinstalling toolbox (and replacing all old launchers) with this
make it clear that 5.x releases require dx redist and vcredist, only 6.x doesn't

played with for 5 hrs today, shockingly enough it worked fine with no bugs

completely got rid of d3dx9, gwtoolbox no longer has any runtime dependencies

Changes summed up:

[x] Update cmake to automatically set win32, update build tool requirement to 142+ 60f4dd2 7906fb0
[x] switch linker settings to static 5d51fe1 33f5ba5
[x] Feature/Functionality: Ask about download if running beta.
[x] version check with dll manifest info 28d9cec
[x] Feature/Functionality: Exe without arguments now prefers local dll, falls back to installation location if not found 73cd4d8
[x] embed font into exe 8fd0668
[x] remove d3dx dependency 9a182cc 46057ed 088eb4b a35d558
[x]  move dependencies from github to cmake fetch content 3f5c443

The rest are all minor code quality changes or additions to support the features mentioned above (for example Core/EmbeddedResource.h)


Refactor test_random.test_shuffle to improve the timings.

Description
Inspired by @larroy thread CI and PRs,
Cut down time on test_random.test_shuffle which almost always takes most time in the unix-CPU from what I have seen.
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-15865/3/pipeline/282
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-15865/3/pipeline/279
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-15865/3/pipeline/280
http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/mxnet-validation%2Funix-cpu/detail/PR-15865/3/pipeline/281
Before the changes, takes 495s on my laptop.
After the changes, takes 117s on my laptop.
Checklist
Essentials
Please feel free to remove inapplicable items for your PR.

[ ] The PR title starts with [MXNET-$JIRA_ID], where $JIRA_ID refers to the relevant JIRA issue created (except PRs with tiny changes)
[ ] Changes are complete (i.e. I finished coding on this PR)
[ ] All changes have test coverage:
Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
[ ] Code is well-documented:
For user-facing API changes, API doc string has been updated.
For new C++ functions in header files, their functionalities and arguments are documented.
For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
[ ] To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

[ ] Feature1, tests, (and when applicable, API doc)
[ ] Feature2, tests, (and when applicable, API doc)

Comments

If this change is a backward incompatible change, why must this change be made.
Interesting edge cases to note here

The function :
https://github.com/apache/incubator-mxnet/blob/40593c6f6c20baed98a914d14987db5438c0a5a5/tests/python/unittest/test_random.py#L894-L903
doesn't make much sense on
https://github.com/apache/incubator-mxnet/blob/40593c6f6c20baed98a914d14987db5438c0a5a5/tests/python/unittest/test_random.py#L967
which is where almost 90% of the time is spent.
Is this check necessary for this case? Just removing the check for this particular case will bring time down drastically.

Closing as #15882 , handles it more gracefully.


Update quota descriptions

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[x] I commit to follow the Breaking Change Policy of “no breaking changes
[x] I have reviewed the documentation for the workflow.
[x] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

/azp run automation - sdk

Can one of the admins verify this patch?

No API changes here, no ARM review required

@arolshan Hi. Do we need this PR or not?

Closed, thanks
Get Outlook for iOShttps://aka.ms/o0ukef

From: MyronFanQiu<EMAIL_ADDRESS>Sent: Wednesday, July 29, 2020 4:55:17 AM
To: Azure/azure-rest-api-specs<EMAIL_ADDRESS>Cc: Arik Olsh<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Azure/azure-rest-api-specs] Update quota descriptions (#10236)
@arolshanhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Farolshan&data=02|01|Arie.Olshanezky%40microsoft.com|6be4a530b50c4e80dc9008d83362714a|72f988bf86f141af91ab2d7cd011db47|1|0|637315845184594337&sdata=aOvl5E%2F3BvVoUNSccQP7C0h5WaMHrQgASvvvIQeDrTs%3D&reserved=0 Hi. Do we need this PR or not?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAzure%2Fazure-rest-api-specs%2Fpull%2F10236%23issuecomment-665384802&data=02|01|Arie.Olshanezky%40microsoft.com|6be4a530b50c4e80dc9008d83362714a|72f988bf86f141af91ab2d7cd011db47|1|0|637315845184594337&sdata=%2FzFf5zR2%2BVZzZQYT27DTh%2F7fazXan5Eiq7SizBaZx%2F8%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FALHNW5PCIAU3IQK7ECFCG2TR556QLANCNFSM4PFPQL7A&data=02|01|Arie.Olshanezky%40microsoft.com|6be4a530b50c4e80dc9008d83362714a|72f988bf86f141af91ab2d7cd011db47|1|0|637315845184604328&sdata=MZpXtPakAm2dNkMTMoSe5QgjWysqCOV9VxsLhhHRW10%3D&reserved=0.


include doc generator in public release

This issue was imported from Closure Library's previous home at http://closure-library.googlecode.com
The link to the original issue is:
https://code.google.com/p/closure-library/issues/detail?id=129

Closure's API docs are now generated with open-source, js-dossier.


What are the Maintaners' intentions with Guidance?

This was my favorite "constrained generation" library, but I'm afraid it's dead. I would like to be wrong.
It's Oct 5, the last commit was >2mo ago, and maintainers have not been involved in replies, vetting Issues nor PRs, nor adding models, nor fixing bugs.
Would you please give a status report of your intentions, or archive this project?
If not, the community should direct their attention at a fork that isn't dead, although I don't know if those maintainers would be serious about carrying the torch. 2 forks have novel commits, and several github stars:

https://github.com/Maximilian-Winter/guidance  adds llama-cpp-python support
https://github.com/paolorechia/local-guidance incorporates a web ui

If not, some similar players in this space are actively maintained:

https://github.com/eth-sri/lmql
https://github.com/outlines-dev/outlines

Thank you for the suggestion of other alternatives, i was wondering the same thing about the repository status.

Not dead - we have been working on a release with lots of big changes (it's taking longer than expected).
Hoping to merge it into master soon

@marcotcr Thanks for the reply! I really did prefer this project over alternatives, but then bugs went uninspected, and PRs unmerged.
Could you tell us about the microsoft -> guidance-ai shift? Who runs the project now, and do they see this as a project they'll want to maintain? I think just giving updates, maybe posting about your future dev plans, etc would go along way to keeping the wind in the community's sails.

Yes, sorry, a lot has happened. Me and @slundberg switched employers, and Microsoft moved the project out to guidance-ai/guidance so that we could continue working on it (they were very nice).
The switch took a while, and we let the project lapse in the meantime. Since we picked it back up, me and Scott have been working on this branch, and more recently on this one with what we thought would be a quick change, but proved to result in a larger refactor that obviates many of the current issues. I think we're close to being ready to release (as in... in a couple of weeks), at which point our plan is to write a blog post, revamp README, examples, etc, and go through all issues that are still relevant.
The new version should be way better, but we'll see how the community responds :)

:heart: Thanks for the update! :heart:

Fantastic to hear this is still in development. There's nothing I found that quite gives me the control over the results of prompt chaining than guidance. Excited to see the update when it comes out.
Syntax highlighting would be a gamechanger so hoping that's on the roadmap. 🙏

Fantastic to hear this is still in development. There's nothing I found that quite gives me the control over the results of prompt chaining than guidance. Excited to see the update when it comes out.
Syntax highlighting would be a gamechanger so hoping that's on the roadmap. 🙏

How about LMQL? I've been thinking about using it instead of guidance but I don't know if anyone has tried both to give an unbiased comparison of them.

Fantastic to hear this is still in development. There's nothing I found that quite gives me the control over the results of prompt chaining than guidance. Excited to see the update when it comes out.
Syntax highlighting would be a gamechanger so hoping that's on the roadmap. 🙏

How about LMQL? I've been thinking about using it instead of guidance but I don't know if anyone has tried both to give an unbiased comparison of them.

Wasn't aware of this package yet, thanks for pointing it out. From what I can see LMQL is limited to completion endpoints/model which would make it less versatile than guidance. There are some interesting ideas there though so I'll definitely check it out.

@Nick-tenBroeke guidance works on fill-in-the-middle models? I wasn't aware. I truly wish this project would revive. Last I tried it it was broken for all my use cases, and relevant issues from other users were ignored :(

I see @marcotcr  recently joined, so I guess this project may have new life at some point? https://github.com/guidance-ai/guidance/commit/302a240b35b51a8626bfb7f8b9beb28fc6359bf4
Welcome @marcotcr!

Hey @freckletonj, thanks for all your interest and passion about Guidance! As Marco mentioned above, we've been focused on completely revamping guidance in the branch here: https://github.com/guidance-ai/guidance/tree/pythonic2, though these changes are still stabilizing (and therefore not ready to pull into main just yet). Lots of progress being made, just not on the default GH homepage view :)

Hey @freckletonj, thanks for all your interest and passion about Guidance! As Marco mentioned above, we've been focused on completely revamping guidance in the branch here: https://github.com/guidance-ai/guidance/tree/pythonic2, though these changes are still stabilizing (and therefore not ready to pull into main just yet). Lots of progress being made, just not on the default GH homepage view :)

Hey, I would love to use the version on the branch. Even if it is not stabilised, can we still test it? Do you have a small example of the new default python file?

I see @marcotcr recently joined, so I guess this project may have new life at some point? https://github.com/guidance-ai/guidance/commit/302a240b35b51a8626bfb7f8b9beb28fc6359bf4

Welcome @marcotcr!

Thank you. I was developing guidance from the very beginning, just hadn't joined the board :)

We finally have a new release, sorry it took us so long :)


Fixing examples links

READ ME PLEASE!
TL;DR: Make sure to add your changes to versioned docs
Thanks for opening a PR!
The docs cover several versions of react-navigation, and in some cases there are several files (for version 1, version 2 and etc.) that all describe a single page of the docs (eg. "Getting Started").
Please make sure that the edit you're making in docs/file-you-edited.md is also included in the file for the correct version, eg. website/versioned_docs/version-3.x/file-you-edited.md for version 3. If such file doesn't exist, please create it. :+1:

Due to the changes to the examples folder on the react-navigation repo, and this PR  https://github.com/react-navigation/react-navigation/pull/6284#issue-316179012 , I have gone through and updated the links to the new example folder link.
I have also gone through and deleted any examples that are no longer in the example folder.
Thank you

Will do

Updated


Implement getFilename for ExternalResource

The mime type detection is based on the filename. This commit adds an implementation of getFilename for ExternalResource so the mime type is also set on external static files.

tx for contributing!


Include not-required assets from data.json

I think it would be useful to include all of the assets in the data.json file for each core, instead of just the ones flagged as required. instead just include that required flag in the api response, for updaters to handle however they want.
this came up because the super gameboy core has both bios files in data.json not listed as required, but..they kind of are.
      {
        "name": "SGB BIOS SNES",
        "id": "0x103",
        "required": false,
        "filename": "sgb_snes.smc",
        "parameters": "0x2",
        "extensions": [
          "smc"
        ],
        "size_exact": null,
       "size_maximum": 522488,
        "address": "0x00000000"
      },
      {
        "name": "SGB BIOS GB",
        "id": "0x104",
        "required": false,
        "filename": "sgb_boot.bin",
        "parameters": "0x2",
        "extensions": [
          "bin"
        ],
        "size_exact": 256,
        "address": "0x60000f00"
      }

looking through a bunch of the new spiritualized cores, the majority of the necessary bios files are all marked with required: false. so i definitely think including them makes sense, otherwise updaters are just going to have to manually maintain a secondary list of required files, which kind of cancels out most of the point of including these in the api
the only thing is it's going to add a bunch of extra unnecessary data to the api response like every core supporting .sav files, and some other random stuff. but i guess thats not a huge deal? not sure if anyone else has a strong opinion on it

If this is still required, feel free to open another issue here https://github.com/openfpga-cores-inventory/analogue-pocket


Czech (cs-cz) language missing

Description
IT WAS in earlier versions but now Czech language is gone.
Steps To Reproduce
No response
Expected behavior
Czech texts
Files Version
2.3.0
Windows Version
Windows 11 22H2 22622.169
Relevant Assets/Logs
For language Bug is not necesary.

We removed a couple of translations with v2.3 as we didn't receive the author's permission to switch the license to MIT. We encourage you to look at our Crowdin project if you're interested in adding a new localization to Files https://crowdin.com/project/files-app).


Update aspnet-core-module.md

Small correction to the documentation, it turns out the request timeout has a validation that requires whole minutes only.

@rockydevnet  shouldn't it be hours:minutes:seconds, with hour, minutes, and seconds as whole numbers?

cc @guardrex

I know it converts the string into a timespan (ticks) and then divides that by 10000 to get milliseconds, which it passes to WinHTTP (prob as dwConnectTimeout). However, YES! the problem reported by @rockydevnet is easy to repro ... I just had it :boom: on me here.
As for a validation that requires whole minutes only, idk about that ... I checked and didn't see that in the module's ref source.
Even if it is broken and requires a fix in the ANCM repo, we probably need to say something here until a patch is issued.

Good catch folks. @pan-wang @jkotalik  Can you confirm?

From what I can tell, it looks like the requestTimeout is being rounded to the nearest minute. Ex: 2:01 would turn into 2:00. This is a quick fix; I'll make an issue for now and fix after the refactor is in.

This is by design. the schema definition for requestTimeout is timespan and the validation is (0,1296000,60) which means the step is 60 seconds. if we really want to change it, we need to change the schema file.

@jkotalik Can you please link your issue to this PR?

https://github.com/aspnet/AspNetCoreModule/issues/270
@scottaddie I was incorrect in my check above. It seems that this validation is done by the schema rather than in code. We would need to update the aspnetcore_schema, which is a more involved process.

@jkotalik In the meantime, should the proposed text change say something like "The requestTimeout value is rounded to the nearest minute"? When you say "rounded", is it using something like Math.Round, Math.Floor, or Math.Ceiling?

@scottaddie I was incorrect in my analysis before. Add "The requestTimeout value must be specified in whole minutes, else it will default to 2 minutes."
I was originally verifying with values just above 2 minutes, so I thought it rounded down to 2 minutes, not that the default is 2 minutes.

@rockydevnet Thank you for your efforts and for bringing this issue to our attention. Also, congratulations on your 1st contribution to the ASP.NET Core docs.


[REVIEW] - Adding examples for DateTime functionality + other example formatting fixes

rerun tests

rerun tests

LGTM other than the comment @dantegd made regarding keeping the note about difference from Pandas API.

With the move from pygdf->cudf and other changes, this got way out of synch with master. Closing and will re-submit as a cleaner PR


Feature component disclosure interaction

The DisclosureInteraction component is an interactive button that expands into a small sheet when clicked. This sheet provides six options (e.g., Project, Task, Note, etc.) and includes a close button to collapse the sheet back to its original state. The component features smooth animations for expanding and collapsing, and is styled using a clean and modern UI design.
Closes #271
https://github.com/user-attachments/assets/89454af4-7770-478a-897e-93de17d1c737

Please use 'lucide-react` icons and improve the animation as well :)

Okay I will work on the issues

I've resolved the requested changes, including Tailwind CSS adjustments, lucide-react icons, and animations. Please review the updates.
https://github.com/user-attachments/assets/dbeec3c6-0de5-487a-b315-8d1c483495d6

I mistakenly triggered the preview-deployment for this pull request. Could you please avoid approving the deployment or cancel the approval request?

@IngaleChinmay04 The deployment is automatic and it's nothing to worry.

I have updated the package.json and added yarn.lock and also steps in mdx file.
Apologies for the inconvenience with these small changes.

Should I remove the yarn.lock file?

I have replcaed the yarn.lock file which was there in main branch to avoid changes

Your PR should not have the yarn.lock file. The build is failing.
Run yarn install --immutable
➤ YN0000: · Yarn [4](https://github.com/codse/animata/actions/runs/11176462640/job/31069877354?pr=278#step:6:5).2.2
➤ YN0000: ┌ Resolution step
Resolution step
➤ YN0000: └ Completed in 0s 2[8](https://github.com/codse/animata/actions/runs/11176462640/job/31069877354?pr=278#step:6:10)3ms
➤ YN0000: ┌ Post-resolution validation
Post-resolution validation
➤ YN0028: The lockfile would have been modified by this install, which is explicitly forbidden.
➤ YN0000: └ Completed
➤ YN0000: · Failed with errors in 0s 387ms

@IngaleChinmay04 please create a fresh PR with only those 3 files. Make sure to pull the latest main first. I am closing this one.


Updating README with info on editing /etc/fstab on UEFI systems

Also added to https://depenguin.me/bsdinstall.html
Not 100% sure how to fit it in, it's only cropped up on the EX43 server.

:+1:


I get routes via mysql，Why every third time should select from mysql again

Get route massege via mysql，Third time through rutes it have to select from mysql again

I have no idea. We also don't have support for getting routes thru a database yet.


Added derivative and Hessian for Beale test function

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (88326ca) 90.61% compared to head (c8bc183) 90.66%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #423      +/-   ##
==========================================
+ Coverage   90.61%   90.66%   +0.04%
==========================================
  Files         162      162
  Lines       20050    20153     +103
==========================================
+ Hits        18168    18271     +103
  Misses       1882     1882

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Log and print statement were not working in topic classfiier

Because of this line in daemon.py
with redirect_stdout(StringIO()), redirect_stderr(StringIO()
logs and print statements were not working in the topic classifier because of which it was difficult to debug the classifier
On removing this line there were getting logs from "transformers" library.
To suppress them code has been added in logger.py and warnings have been suppressed in topic_classifier.py
You can check the below image to see the difference
Before

After

@gr8nishan LGTM. Let's merge this after 0.1.14 goes out.


[Chapter 17] - Autoencoder missing Dropout or Gaussian Noise

For Question #9 - Should this model include a Dropout or Gaussian Noise layer to be considered a denoising autoencoder? Between Flatten and the first Dense layer?
pretrained_clf = keras.models.Sequential([
    conv_encoder_clone,
    keras.layers.Flatten(),
    keras.layers.Dense(20, activation="selu"),
    keras.layers.Dense(10, activation="softmax")
])

Also the solutions for Chapter 17 include the solution to the Semantic Hashing problem but this is a question in the 1st edition and not the 2nd.

Hi @dleacock ,
Thanks for your question. You want to include a dropout layer or a Gaussian noise layer (whichever you prefer) directly as the first layer in your model, and the model must output an image. The labels during training should just be the input images. Once you are satisfied with your model, you can reuse the first few layers (excluding the dropout or Gaussian noise layer) to create a classification model. Since you are reusing the pretrained model, you should freeze the reused layers for the first few training epochs, then unfreeze them and continue training with a lower learning rate.
I'm currently working on the solutions to the coding exercises in Chapter 16, and I'll work on Chapter 17 just after that.
Hope this helps!


Limiting the parsys does not work when pasting multiple paragraphs

Required Information

[ ] AEM Version, including Service Packs, Cumulative Fix Packs, etc: 6.3
[ ] ACS AEM Commons Version: 3.17.4
[ ] Reproducible on Latest? yes

Expected Behavior
When pasting multiple paragraphs the parsys should count if there are enough free slots available based on the limitation and how many paragraphs are already in place.
Actual Behavior
The parsys allows to paste, all at once, more elements than the capacity available. So if there is only one available slot, I'm still able to paste 2 paragraphs, all at once.
Steps to Reproduce

Limit the parsys to 2 paragraphs.
Paste 3 paragraphs, all at once.

Related PR: https://github.com/Adobe-Consulting-Services/acs-aem-commons/pull/1577/commits


Add Support for WineHQ Wines

Separate functions for winehq-stable -devel and -staging with supported releases of Debian (and Mint) and Ubuntu.
Fixes #427

Close, but they are giving signing key issues ....

The format of package definitions has changed. Please read 01-main/CONTRIBUTING and EXTREPO, update your implementation and submit a new PR.


[🐞] Error: Code(10): QRL is not a function in v1.2.6 with a --mode build argument

Which component is affected?
Qwik Runtime
Describe the bug
After upgrading from 1.2.4 to 1.2.6, I can no longer run my app in preview or production with a custom --mode argument to change the env file used.
The error happens as soon as an interaction happens on the frontend, like a onScroll$ or Link is clicked.
 I'm more than willing to jump on a call to debug it, or help in any other way!
Thanks!!

Steps to reproduce
No response
System Info
N/A

Additional Information
I cant reproduce it at all.

I'm having the exact same problem. Did you find a solution?

I'm really sorry, but I need a repro... If you can't reproduce it, how can I?
What is root2.js: That is not a standard Qwik bundle artifact.
The error means that the lazy loaded chunk is not a function and you are trying to invoke it as a function.
Sorry until I have a repro I am going to close this.

Thanks @mhevery, I know its not easy without a repro.. If i manage to recreate it I'll reopen the issue.
@tuurbo i havent fixed it yet since I cant find exactly whats causing it after a few hours of trying. I'm stuck using Qwik v1.2.4 unfortunately.
I suspect it started with this PR https://github.com/BuilderIO/qwik/pull/4719/ but I cant be 100% sure.
In a few weeks when I have capacity again, I'll have another crack at recreating it.

So if you see a version that works and a version that does not, can you try to bisect it?
Every change has a build here: https://github.com/BuilderIO/qwik-build/ and https://github.com/BuilderIO/qwik-city-build
You can install any one of them in you package.json like so
<EMAIL_ADDRESS>"github:BuilderIo/qwik-build#SHA",
<EMAIL_ADDRESS>"github:BuilderIo/qwik-city-build#SHA",

So if you think it started with #4719 then this should fail:
<EMAIL_ADDRESS>"github:BuilderIo/qwik-build#97d8f9345daa09e0fb178870494ac4657591279b",
<EMAIL_ADDRESS>"github:BuilderIo/qwik-city-build#6df2b45ffe54b0cb8557aa1d54b1d1fa5aafddd6",

But this should work
<EMAIL_ADDRESS>"github:BuilderIo/qwik-build#eeb419ec1479799783059b84a33d372050bdfa71",
<EMAIL_ADDRESS>"github:BuilderIo/qwik-city-build#968c68ee5dd430eceb8e47b873e4ac99d818c34a",

Unfortunately Qwik has some erroneous code merged in when this issue was created, so its not possible to run Qwik and find the exact moment this issue was introduced. However, here are the commits when this issue didn't exist before, and after the other error was fixed the issue began. So somewhere in here lies the problem.
I'll keep digging.
https://github.com/BuilderIO/qwik/compare/8bdcb24...3e7e5e5
The root2.js file seems to be the root.tsx file being compiled weirdly

@DustinJSilk instead of in a blank repo, can you start from your repo and remove everything that doesn't trigger the issue?
Meaning, if you remove it, the issue still happens.

I've managed to create a tiny repo that gives an almost identical error. I'm certain this is it: https://github.com/DustinJSilk/qwik-issue-code-10
The issue exists when building for preview or production when using a --mode argument to select which .env file to use with vite.
You can run pnpm preview to see it working, and pnpm preview-mode to see it broken and not working after clicking on screen.
I've tested it with versions 1.2.4, 1.2.6, 1.2.13, and 1.2.15 and the issue exists in all except for 1.2.4: https://github.com/BuilderIO/qwik/compare/8bdcb24...3e7e5e5.
Could we reopen this issue please? 😄

I've tested it with versions 1.2.4, 1.2.6, 1.2.13, and 1.2.15 and the issue exists in all except for 1.2.4: 8bdcb24...3e7e5e5.

Can you bisect the exact change that is causing this? See instructions here: https://github.com/BuilderIO/qwik/blob/main/CONTINUOUS_BUILD.md

Thanks @mhevery !
The issues starts from commit https://github.com/BuilderIO/qwik/commit/60b37a90340e0d3f9f0f392c30c90fdf325f04e6
(FYI - to run that commit youd need to cherry pick/build/link Qwik with https://github.com/BuilderIO/qwik/commit/3e7e5e5a8da40399f977b46e9259b4f7c77de69e)

I've managed to find a workaround! It would be great if the Qwik CLI had an option to load a specific env file without disrupting the build modes, but this works in the meantime.
The solution is to manually load and define the env file in vite.config.ts.
So you would build/preview with a command such as:
VITE_MODE=staging qwik build preview && VITE_MODE=staging vite preview --open
vite.config.ts:
export default defineConfig(({ mode }) => {
  const env = loadEnv(process.env.VITE_MODE || mode, process.cwd(), 'PUBLIC')

  const define: Record<string, string> = {}
  for (const e of Object.entries(env)) {
    define[`import.meta.env.${e[0]}`] = JSON.stringify(e[1])
  }

  return {
    define: define,
    plugins: [qwikCity(), qwikVite(), tsconfigPaths()],
    preview: {
      headers: {
        "Cache-Control": "public, max-age=600",
      },
    },
  };
});

This is so exciting, I cant wait to update my Qwik version again 😄

node 20 has a way to specify env file

Hey - it seems I'm late to this party ...
Still - I've spent the last few days chasing this bug and preparing a minimal repro so here it is
https://github.com/gparlakov/qwik-ssg-bug-repro
Steps in readme.md

Nice! But I don’t think this will get fixed unfortunately.
I got build time env variables for each environment to work with a bash script to rename each env file before building in each environment.
I haven’t tried the node 20 API yet

well it works if you make sure you don't define components in the same file.

import { CategoryFilter } from "./cat-filter";

export const MovementFilter = component$(() => {
  return (
    <div>
      {/*  */}
      <CategoryFilter />
      {/*  */}
    </div>
  );
});

if this component is in the same file then it breaks for some reason. likely optimizer error

actually this is likely related to the preload vite bug that qwik-ui ran into

Oh I'm surprised that this got so much traction.
@PatricJS thanks for looking into it. And yes I'm aware that a separate
file component does work.
To be honest I was not going to comment were it not for a few days of
debugging I did before that. You know since the issue was closed.
On Sun, May 12, 2024, 11:33 AM PatrickJS @.***> wrote:

well it works if you make sure you don't define components in the same
file.
import { CategoryFilter } from "./cat-filter";
export const MovementFilter = component$(() => {
return (

{/*  /}

{/  */}

);});
if this component is in the same file then it breaks for some reason.
likely optimizer error
—
Reply to this email directly, view it on GitHub
https://github.com/QwikDev/qwik/issues/4779#issuecomment-2106166785, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AA2SEV7CGC4V3KQ3FWYIJTDZB4SL3AVCNFSM6AAAAAA2GHYXW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBWGE3DMNZYGU
.
You are receiving this because you commented.Message ID:
@.***>

@gparlakov don't hold back 👍 the repro you did was really helpful
yeah this is vite hoisting files and qwik conflicting. both are doing the same thing and when vite is turned on the qwik gets all messed up. I think vite might of had a regression or their api changed.

we can say in the docs components should be separated one per file until we figure out the fix.

@PatrickJS Damn, do we have a turn around to this? My whole project has multiple components in the same file and it will be a mess to split things up

@fprl well only split if you run into the problem. @wmertens do we still have this issue in v2?

@fprl well only split if you run into the problem. @wmertens do we still have this issue in v2?

I ran into the same error in production build: Error: Code(10) and it was not clear where the issue was coming until I comment out a lot of components and realised that I was importing Link from qwik-city in some places and also Link from my ui package in my monorepo so it was related to a naming collision.

What a tricky bug.
I nailed it down to my use of quik-ui Modal. Removing that component avoided the issue for me.
Particularly was occurring after a Form action (from globalAction$) completed.
It appears, thank to Dustin's repro, that this has to do with SessionContext which I believe the modal uses under the hood. Strangely, I was able to avoid the issue iff I didn't reference action.value, which of course was not a practical stop gap.
Hope this helps.

To nobody's discredit, I was just trialing qwik, and ran into this bug pretty quickly. This worried me about stability (particularly because this issue started ~1yr ago), so I begrudgingly may just go back to solidstart or next.
I wonder if this is a reflection of the utter difficulty of writing compilers (optimizers, etc) for vite and in javascript land in general. I looked at the code and it's pretty tough stuff. Maybe there are too many abstractions at hand and we need to do something more fundamental. I have to say I found for instance solidstart's stack-on-stack-on-stack business (vite,vinxi, blah blah) a bit of a head scratcher.
I'd be open to investing a lot of time in this if anyone has ideas.

So in the current qwik@dev version, naming collisions in qrl segments are fixed.
@nolanholden could you try if that fixes your issue?
I agree that the optimization is very complex, I'm trying to simplify it as much as possible :sweat_smile:

@nolanholden you can install the continuous releases with these packages https://github.com/QwikDev/qwik/runs/26508673662

@gparlakov I can confirm that your repro is fixed with qwik@dev

@wmertens / @gioboa  Fixed the issue in preview/prod mode!  Polling for restart...

A couple things to note:

culprit is inside qwik-ui (@qwik-ui/headless/components/modal/hmodalpanel_component_usetask_lr6cnk1egkg.js)
I am using a pnpm monorepo — you can see <REDACTED> is my fully qualified macos /Users/.../repo path, to the pnpm workspace (a parent of the qwik package dir), not the path to the qwik project.

I made sure to clear caches & clean (git clean -ffxd) the whole monorepo & reinstall, so I suspect it's a real issue.
I also see that qwik-ui is correctly using qwik as a peer dependency, so shouldn't be issues there either?
Any ideas? (@wmertens )

Ok I see. I added URI encoding in dev mode because paths included + and those turn into spaces otherwise. Looks like I have to decode then on the plugin side. Will push fix soon

Hmm it will have to wait until tomorrow. I ran into another edge case, but I have an idea.

ok should be fixed in #6590

@wmertens can we finally close this issue 🙌

I don't know :) I need confirmation from @gparlakov and @nolanholden that the current qwik@dev version works...

where can I find the new build package? I looked for a while but couldn't figure it out. Looked like ci skipped building the merge commit

@nolanholden you just use dev as the version in the package.JSON file for both qwik and qwik-city

I see. Just tried with
<EMAIL_ADDRESS>"1.5.7-dev20240622232308",
<EMAIL_ADDRESS>"1.5.7-dev20240622232308",

Still seeing errors under pnpm run dev (console logs below, server logs are clean), with routeActions and other qrls failing "dynamically" fetch.

I suppose you can't share a repro?
Do you see any error messages in the logs, mentioning the word 'parent'?

I'm so swamped, it may be a while til I can.
I removed a LOT to get it to work — but it was too big of a haystack for
now.
A couple possible culprits:

I'm breaking lots of conventions by colocating many components and route
handlers in a single route file.
I'm using turborepo with a pnpm workspace, so dependencies are in a
non-usual relative path
I'm indeed using pnpm workspace dependencies from the filesystem (non-npm)
I'm not certain where some of my dependencies should go; there are a few
in "dependencies" which may not be server-only? I still don't quite get the
right thing to do here.

I did it some points see "parent" in error messages, but not largely.
Largely it was 'failed to dynamically import'
..._blah_blah_blah_usevisibletask or ..._routeaction etc. Sometimes just
commenting out the code, e.g. commenting away the useVisibleTask would
'fix' the issue (or push the problem elsewhere). I did find i was not
re-exporting a globalAction, but after fixing this i still saw the issue.
Sorry, I wish I could spend more time on it now.
In general, I'm leaning heavily toward rolling my own little framework,
because, although the granular/default code splitting is quite powerful, I
just want resumability/no-hydration! So in my particular case the
auto-splitting unfortunately amounts to a lot of extra engineering under
the hood which is problem surfacearea for us, at least while our app is so
small.
I like that there are options in the ssr config to prefetch everything
aggressively (there must be 7–8 options, which I currently have all
enabled, shown below), but still that doesn't prevent these service
worker(?) fetching issues, which makes sense.
src/entry.ssr.tsx
export default function (opts: RenderToStreamOptions) {
  return renderToStream(<Root />, {

    qwikLoader: {
      include: 'always',
      position: 'top',
    },

    prefetchStrategy: {
      implementation: {
        // Expectation: this takes place sooner than 'js-append', but
without downsides otherwise.
        linkInsert: 'html-append',

        // Expectation: more expensive up-front (more blocking HTTP bytes),
but more responsive later, than both 'prefetch' and 'preload'
        //
https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/rel/modulepreload
        linkRel: 'modulepreload',

        workerFetchInsert: 'always',

        prefetchEvent: 'always',
      },

      // From docs:
      // > Auto: Prefetch all possible QRLs used by the document. Default.
      symbolsToPrefetch: 'auto',
    },

    // ...
  });
}

On Mon, Jun 24, 2024 at 5:26 PM Wout Mertens @.***>
wrote:

@nolanholden https://github.com/nolanholden hmm annoying, not sure how
it asked for that without the ?_qrl_parent parameter.
I suppose you can't share a repro?
Do you see any error messages in the logs, mentioning the word 'parent'?
—
Reply to this email directly, view it on GitHub
https://github.com/QwikDev/qwik/issues/4779#issuecomment-2186843294, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AGDQAECFUAJYNZZ52GUWALDZJA3DLAVCNFSM6AAAAAA2GHYXW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBWHA2DGMRZGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

@nolanholden appreciate any time you can spend to help find the issue.
Note that these particular errors are only present during dev mode. The puzzling one for me is the URI-encoded request that should come with a _qrl_parent search parameter but doesn't. Ideally I'd like to know the initiator of that request.
As for your own framework: you can't get useful resuming without code splitting, and code splitting is useless unless there's no parent child coupling.
As for the bundling, you should configure vite so that everything is bundled, both on server and client (obviously). The only exceptions are binary dependencies. That means that your dependencies should only include exactly those packages that are needed on the server in production.
I'd be happy to jump on a short call with you to debug the issue and discuss.

@nolanholden I think 1.7.1 fixes all the issues (but not on Windows quite yet)

im not sure, but since there are a few work arounds documented here we can probably close this issue


KNOX-2024 - KnoxShellTable - Case Insensitive Operations with Col Names

What changes were proposed in this pull request?
Case sensitivity for column names in table filtering
How was this patch tested?
Manual and unit tests

In regards to the failed check, it builds fine on my machine, unsure why it's failing on here but it doesn't seem to be from my change.

Most likely going to want to rebase this change on top of PR #157


add support for joins against local tables

This PR adds support for joining against local tables. The remaining work here was to allow dplyr to use copy_to to transfer the local table into Spark. See example from https://github.com/rstudio/sparklyr/issues/215:
n = 1000000
x = data.table(id = 1:n, val = rnorm(n), t = 1:10)
x_spark = sc %>% copy_to(x, overwrite = T)
ts = data.table(t = 1:10, name = letters[1:10])

x_spark %>%
  group_by(t) %>%
  summarize(m = mean(val)) %>%
  arrange(t) %>%
  inner_join(ts, by = c('t'), copy = T)

We are holding off all PR, with the CRAN checkpoint to be performed (ETA) this Thursday. If someone needs this fix, one way yo get this is to use devtools:
devtools::install_github(
   "https://github.com/rstudio/sparklyr",
   ref = "feature/join-local-tables")


Boox Note Air - works!

Just stopped by and wanted to say thank you for the work you put into this! :heart:
I can confirm that it also works for the original Note Air device - not only for Note Air 2:
I installed the current state of vboox on my Linux machine (ArchLinux, GNOME, Wayland), compiled and ran it. After I selected Note Air 2 device, I'm able to remote control the mouse using the Note Air as external tablet - very neat!
So again, thank you very much! Any plans in (potential) deeper system integration such as a systemd service or so?

Just stopped by and wanted to say thank you for the work you put into this! ❤
I can confirm that it also works for the original Note Air device - not only for Note Air 2: I installed the current state of vboox on my Linux machine (ArchLinux, GNOME, Wayland), compiled and ran it. After I selected Note Air 2 device, I'm able to remote control the mouse using the Note Air as external tablet - very neat!
So again, thank you very much! Any plans in (potential) deeper system integration such as a systemd service or so?

I don't actually use systemd (openrc) and the way I do it on my system is just in my xprofile: overall it is a bit hacky as I have left it right now, because after you set it up it just works.
There is a "daemon" script on the repo "vbooxd.sh" and you can set it to run in the background with:
setsid -f sh -c "exec ./vbooxd.sh $1 2>&1 > /dev/null"

This script is not tested outside of my own machines however it should poll over an interval of 10 seconds to see if there is a device and try to launch vboox in the backround.

Just stopped by and wanted to say thank you for the work you put into this! ❤
I can confirm that it also works for the original Note Air device - not only for Note Air 2: I installed the current state of vboox on my Linux machine (ArchLinux, GNOME, Wayland), compiled and ran it. After I selected Note Air 2 device, I'm able to remote control the mouse using the Note Air as external tablet - very neat!
So again, thank you very much! Any plans in (potential) deeper system integration such as a systemd service or so?

Also thanks for testing it out ! I am not surprised that it worked despite setting NoteAir2 as the device: I think most of the devices use the exact same digitizer however I could not make this assumption while developing as I did not find any specs for the devices (I emailed boox directly about it to no avail also).