Waiting for Deployment ingress-nginx-controller or  my-gitea to become ready never ends

What is your environment, configuration, and command?
Fedora 41 64 bit hyper-V VM
Followed instructions at https://cnoe.io/docs/reference-implementation/installations/idpbuilder/quick-start using RPM package
Docker destop works fine
What did you do and What did you see instead?
I ran
idpbuilder create
VM named local-dev-control created .On the command line, since 3 hours, I have the following output that never ends, it gets printed every 1 minute as if idpbuilder is not able to continue
ild.name=localdev namespace="" name=localdev reconcileID=67d99153-bba2-492a-85c3-0786cb6c6069
time=2024-11-01T18:32:27.900+01:00 level=INFO msg="Waiting for Deployment ingress-nginx-controller to become ready" controller=localbuild controllerGroup=idpbuilder.cnoe.io controllerKind=Localbuild Localbuild.name=localdev namespace="" name=localdev reconcileID=b96fa8dd-5d4e-4a74-9c5a-d1c627171169
time=2024-11-01T18:32:30.621+01:00 level=INFO msg="Waiting for Deployment ingress-nginx-controller to become ready" controller=localbuild controllerGroup=idpbuilder.cnoe.io controllerKind=Localbuild Localbuild.name=localdev namespace="" name=localdev reconcileID=67d99153-bba2-492a-85c3-0786cb6c6069
time=2024-11-01T18:32:50.619+01:00 level=INFO msg="Waiting for Deployment my-gitea to become ready" controller=localbuild controllerGroup=idpbuilder.cnoe.io controllerKind=Localbuild Localbuild.name=localdev namespace="" name=localdev reconcileID=b96fa8dd-5d4e-4a74-9c5a-d1c627171169
time=2024-11-01T18:32:56.926+01:00 level=INFO msg="Waiting for Deployment my-gitea to become ready" controller=localbuild controllerGroup=idpbuilder.cnoe.io controllerKind=Localbuild Localbuild.name=localdev namespace="" name=localdev reconcileID=67d99153-bba2-492a-85c3-0786cb6c6069
time=2024-11-01T18:32:57.900+01:00 level=INFO msg="Waiting for Deployment ingress-nginx-controller to become ready" controller=localbuild controllerGroup=idpbuilder.cnoe.io controllerKind=Localbuild Localbuild.name=localdev namespace="" name=localdev reconcileID=b96fa8dd-5d4e-4a74-9c5a-d1c627171169
time=2024-11-01T18:33:00.621+01:00 level=INFO msg="Waiting for Deployment ingress-nginx-controller to become ready" controller=localbuild controllerGroup=idpbuilder.cnoe.io controllerKind=Localbuild Localbuild.name=localdev namespace="" name=localdev reconcileID=67d99153-bba2-492a-85c3-0786cb6c6069

When I try to access https://argocd.cnoe.localtest.me:8443/ or https://gitea.cnoe.localtest.me:8443/ I get

Here is a snpashot of the terminal

Ths log of the VM in docker desktop does not seem has any issue

Additional Information. .
I killed the process with Ctrl + C, surprisingly, I got a message indicating ArgoCD was created successfyly, I can get its password but still cant access it in firefox

Hmm interesting. Can you give me the output of this command? I am guessing there was an issue with pod creation.
kubectl describe pod -n ingress-nginx

Do you see any errors in the ingress nginx pod?
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller

Thanks @nabuskey , in fact, 1st, when I tried to run anu kubectl command, I was getting
command not found and discovered the Docker desktop installation on Fedora did not bring with it kubectl, nor kubeadm nor kubelet.
I did install them manually then I rerun the  command
idpbuilder create
It creates the kind pods then it errors as follows

$ idpbuilder create
time=2024-11-02T12:13:16.892+01:00 level=INFO msg="Creating kind cluster" logger=setup
time=2024-11-02T12:13:16.913+01:00 level=INFO msg="Runtime detected" logger=setup provider=docker
########################### Our kind config ############################
Kind kubernetes release images https://github.com/kubernetes-sigs/kind/releases
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:

role: control-plane
image: "kindest/node:v1.29.2"
kubeadmConfigPatches:

|
kind: InitConfiguration
nodeRegistration:
kubeletExtraArgs:
node-labels: "ingress-ready=true"
extraPortMappings:
containerPort: 443
hostPort: 8443
protocol: TCP

containerdConfigPatches:

|-
[plugins."io.containerd.grpc.v1.cri".registry.mirrors."gitea.cnoe.localtest.me:8443"]
endpoint = ["https://gitea.cnoe.localtest.me"]
[plugins."io.containerd.grpc.v1.cri".registry.configs."gitea.cnoe.localtest.me".tls]
insecure_skip_verify = true

#########################   config end    ############################
time=2024-11-02T12:13:16.949+01:00 level=INFO msg="Creating kind cluster" logger=setup cluster=localdev
time=2024-11-02T12:19:04.217+01:00 level=ERROR msg="Error starting kind cluster" logger=setup err="command "docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1\nsigs.k8s.io/kind/pkg/errors.WithStack\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/errors/errors.go:59\nsigs.k8s.io/kind/pkg/exec.(*LocalCmd).Run\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/exec/local.go:124\nsigs.k8s.io/kind/pkg/cluster/internal/providers/docker.(*nodeCmd).Run\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/providers/docker/node.go:146\nsigs.k8s.io/kind/pkg/exec.CombinedOutputLines\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/exec/helpers.go:67\nsigs.k8s.io/kind/pkg/cluster/internal/create/actions/kubeadminit.(*action).Execute\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/actions/kubeadminit/init.go:81\nsigs.k8s.io/kind/pkg/cluster/internal/create.Cluster\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/create.go:135\nsigs.k8s.io/kind/pkg/cluster.(*Provider).Create\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/provider.go:192\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Reconcile\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:202\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).ReconcileKindCluster\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:85\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).Run\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:133\ngithub.com/cnoe-io/idpbuilder/pkg/cmd/create.create\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/create/root.go:139\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:983\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039\ngithub.com/cnoe-io/idpbuilder/pkg/cmd.Execute\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/root.go:30\nmain.main\n\t/home/runner/work/idpbuilder/idpbuilder/main.go:6\nruntime.main\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/proc.go:267\nruntime.goexit\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/asm_amd64.s:1650\nfailed to init node with kubeadm\nsigs.k8s.io/kind/pkg/errors.Wrap\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/errors/errors.go:47\nsigs.k8s.io/kind/pkg/cluster/internal/create/actions/kubeadminit.(*action).Execute\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/actions/kubeadminit/init.go:84\nsigs.k8s.io/kind/pkg/cluster/internal/create.Cluster\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/create.go:135\nsigs.k8s.io/kind/pkg/cluster.(*Provider).Create\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/provider.go:192\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Reconcile\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:202\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).ReconcileKindCluster\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:85\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).Run\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:133\ngithub.com/cnoe-io/idpbuilder/pkg/cmd/create.create\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/create/root.go:139\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:983\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039\ngithub.com/cnoe-io/idpbuilder/pkg/cmd.Execute\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/root.go:30\nmain.main\n\t/home/runner/work/idpbuilder/idpbuilder/main.go:6\nruntime.main\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/proc.go:267\nruntime.goexit\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/asm_amd64.s:1650"
Error: failed to init node with kubeadm: command "docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1
Usage:
idpbuilder create [flags]
Flags:
--build-name string             Name for build (Prefix for kind cluster name, pod names, etc). (default "localdev")
--extra-ports string            List of extra ports to expose on the docker container and kubernetes cluster as nodePort (e.g. "22:32222,9090:39090,etc").
-h, --help                          help for create
--host string                   Host name to access resources in this cluster. (default "cnoe.localtest.me")
--ingress-host-name string      Host name used by ingresses. Useful when you have another proxy in front of ingress-nginx that idpbuilder provisions.
--kind-config string            Path of the kind config file to be used instead of the default.
--kube-version string           Version of the kind kubernetes cluster to create. (default "v1.29.2")
-n, --no-exit                       When set, idpbuilder will not exit after all packages are synced. Useful for continuously syncing local directories. (default true)
-p, --package strings               Paths to locations containing custom packages
-c, --package-custom-file strings   Name of the package and the path to file to customize the package with. e.g. argocd:/tmp/argocd.yaml
--port string                   Port number under which idpBuilder tools are accessible. (default "8443")
--protocol string               Protocol to use to access web UIs. http or https. (default "https")
--recreate                      Delete cluster first if it already exists.
--use-path-routing              When set to true, web UIs are exposed under single domain name.
Global Flags:
-l, --log-level string   Set the log verbosity. Supported values are: debug, info, warn, and error. (default "info")
failed to init node with kubeadm: command "docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1

I dont see any ingress-nginx pod created so the command
kubectl describe pod -n ingress-nginx
fails with the following error
$ kubectl describe pod -n ingress-nginx
E1102 12:24:00.238351    7501 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp [::1]:8080: connect: connection refused"
E1102 12:24:00.240173    7501 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp [::1]:8080: connect: connection refused"
E1102 12:24:00.242138    7501 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp [::1]:8080: connect: connection refused"
E1102 12:24:00.243849    7501 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get \"http://localhost:8080/api?timeout=32s\": dial tcp [::1]:8080: connect: connection refused"

I rebooted the VM, when I issue the create command getting another error

Any idea please?

Were you able to resolve this? You shouldn't need to  install kubeadm or kubelet. All you need is docker.
The kubectl output seems to indicate your kubeconfig is misconfiugred somehow. Do you have a valid kubeconfig? ~/.kube/config Is it pointing to the right port and host?

No Sir. I think yes it is correct, here is the content of .kube/config

and when I run
 kubectl config get-contexts
It points to the right cluster

You seem to have another cluster created by docker? When idpbuilder creates a cluster, by default, it creates a cluster inside of a docker container, and it is named localdev-control-plane. Let's try...

Run docker container ls -a. Do you see a container with the name localdev-control-plane?
If you see a container with the name, delete it. docker rm -f localdev-control-plane.
Run idpbuilder create.
If this gets stuck (more than 3 min), then run kubectl describe deployments -n ingress-nginx and kubectl get pods -n ingress-nginx.
If you see pods with the name pattern like ingress-nginx-controller-<RANDOM_CHARS> running, run kubectl -n ingress-nginx logs deployment/ingress-nginx-controller. Note any error messages.

Hi, no thers is no such container localdev-control-plane. Do you mean I should stop kubernetes to run in Docker desktop settings?
I tried running
sudo idpbuilder create
I get right away the following on the terminal
time=2024-11-05T18:40:34.840+01:00 level=INFO msg="Creating kind cluster" logger=setup
time=2024-11-05T18:40:34.901+01:00 level=INFO msg="Runtime detected" logger=setup provider=docker
time=2024-11-05T18:40:34.934+01:00 level=ERROR msg="Error starting kind cluster" logger=setup err="command \"docker ps -a --filter label=io.x-k8s.kind.cluster --format '{{.Label \"io.x-k8s.kind.cluster\"}}'\" failed with error: exit status 1\nsigs.k8s.io/kind/pkg/errors.WithStack\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/errors/errors.go:59\nsigs.k8s.io/kind/pkg/exec.(*LocalCmd).Run\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/exec/local.go:124\nsigs.k8s.io/kind/pkg/exec.OutputLines\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/exec/helpers.go:81\nsigs.k8s.io/kind/pkg/cluster/internal/providers/docker.(*provider).ListClusters\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/providers/docker/provider.go:107\nsigs.k8s.io/kind/pkg/cluster.(*Provider).List\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/provider.go:202\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Exists\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:128\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Reconcile\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:167\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).ReconcileKindCluster\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:85\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).Run\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:133\ngithub.com/cnoe-io/idpbuilder/pkg/cmd/create.create\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/create/root.go:139\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:983\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039\ngithub.com/cnoe-io/idpbuilder/pkg/cmd.Execute\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/root.go:30\nmain.main\n\t/home/runner/work/idpbuilder/idpbuilder/main.go:6\nruntime.main\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/proc.go:267\nruntime.goexit\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/asm_amd64.s:1650\nfailed to list clusters\nsigs.k8s.io/kind/pkg/errors.Wrap\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/errors/errors.go:47\nsigs.k8s.io/kind/pkg/cluster/internal/providers/docker.(*provider).ListClusters\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/providers/docker/provider.go:109\nsigs.k8s.io/kind/pkg/cluster.(*Provider).List\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/provider.go:202\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Exists\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:128\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Reconcile\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:167\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).ReconcileKindCluster\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:85\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).Run\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:133\ngithub.com/cnoe-io/idpbuilder/pkg/cmd/create.create\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/create/root.go:139\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:983\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039\ngithub.com/cnoe-io/idpbuilder/pkg/cmd.Execute\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/root.go:30\nmain.main\n\t/home/runner/work/idpbuilder/idpbuilder/main.go:6\nruntime.main\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/proc.go:267\nruntime.goexit\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/asm_amd64.s:1650"
Error: failed to list clusters: command "docker ps -a --filter label=io.x-k8s.kind.cluster --format '{{.Label "io.x-k8s.kind.cluster"}}'" failed with error: exit status 1
Usage:
  idpbuilder create [flags]

Flags:
      --build-name string             Name for build (Prefix for kind cluster name, pod names, etc). (default "localdev")
      --extra-ports string            List of extra ports to expose on the docker container and kubernetes cluster as nodePort (e.g. "22:32222,9090:39090,etc").
  -h, --help                          help for create
      --host string                   Host name to access resources in this cluster. (default "cnoe.localtest.me")
      --ingress-host-name string      Host name used by ingresses. Useful when you have another proxy in front of ingress-nginx that idpbuilder provisions.
      --kind-config string            Path of the kind config file to be used instead of the default.
      --kube-version string           Version of the kind kubernetes cluster to create. (default "v1.29.2")
  -n, --no-exit                       When set, idpbuilder will not exit after all packages are synced. Useful for continuously syncing local directories. (default true)
  -p, --package strings               Paths to locations containing custom packages
  -c, --package-custom-file strings   Name of the package and the path to file to customize the package with. e.g. argocd:/tmp/argocd.yaml
      --port string                   Port number under which idpBuilder tools are accessible. (default "8443")
      --protocol string               Protocol to use to access web UIs. http or https. (default "https")
      --recreate                      Delete cluster first if it already exists.
      --use-path-routing              When set to true, web UIs are exposed under single domain name.

Global Flags:
  -l, --log-level string   Set the log verbosity. Supported values are: debug, info, warn, and error. (default "info")

failed to list clusters: command "docker ps -a --filter label=io.x-k8s.kind.cluster --format '{{.Label "io.x-k8s.kind.cluster"}}'" failed with error: exit status 1

For the command
kubectl describe deployments -n ingress-nginx
I get

E1105 18:42:25.925570   10456 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: Get "http://localhost:8080/api?timeout=32s\": dial tcp <IP_ADDRESS>:8080: connect: connection refused"

Do you mean I should stop kubernetes to run in Docker desktop settings?

If you are running a k8s cluster with docker desktop, that's fine. I don't foresee it being an issue.

You shouldn't need to run idpbuilder with root privilege as long as docker is setup correctly.

Nothing

I ran
idpbuilder create, it created localdev-control-plane

I waited almost for 5 minutes then errored as follows, and localdev-control-plane disappeared from the containers list
[salam@demosfedora41 ~]$ idpbuilder create
time=2024-11-05T20:21:54.922+01:00 level=INFO msg="Creating kind cluster" logger=setup
time=2024-11-05T20:21:54.943+01:00 level=INFO msg="Runtime detected" logger=setup provider=docker
########################### Our kind config ############################
# Kind kubernetes release images https://github.com/kubernetes-sigs/kind/releases
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  image: "kindest/node:v1.29.2"
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"
  extraPortMappings:
  - containerPort: 443
    hostPort: 8443
    protocol: TCP

containerdConfigPatches:
- |-
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gitea.cnoe.localtest.me:8443"]
    endpoint = ["https://gitea.cnoe.localtest.me"]
  [plugins."io.containerd.grpc.v1.cri".registry.configs."gitea.cnoe.localtest.me".tls]
    insecure_skip_verify = true

#########################   config end    ############################
time=2024-11-05T20:21:55.000+01:00 level=INFO msg="Creating kind cluster" logger=setup cluster=localdev
time=2024-11-05T20:27:21.580+01:00 level=ERROR msg="Error starting kind cluster" logger=setup err="command \"docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6\" failed with error: exit status 1\nsigs.k8s.io/kind/pkg/errors.WithStack\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/errors/errors.go:59\nsigs.k8s.io/kind/pkg/exec.(*LocalCmd).Run\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/exec/local.go:124\nsigs.k8s.io/kind/pkg/cluster/internal/providers/docker.(*nodeCmd).Run\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/providers/docker/node.go:146\nsigs.k8s.io/kind/pkg/exec.CombinedOutputLines\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/exec/helpers.go:67\nsigs.k8s.io/kind/pkg/cluster/internal/create/actions/kubeadminit.(*action).Execute\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/actions/kubeadminit/init.go:81\nsigs.k8s.io/kind/pkg/cluster/internal/create.Cluster\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/create.go:135\nsigs.k8s.io/kind/pkg/cluster.(*Provider).Create\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/provider.go:192\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Reconcile\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:202\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).ReconcileKindCluster\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:85\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).Run\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:133\ngithub.com/cnoe-io/idpbuilder/pkg/cmd/create.create\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/create/root.go:139\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:983\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039\ngithub.com/cnoe-io/idpbuilder/pkg/cmd.Execute\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/root.go:30\nmain.main\n\t/home/runner/work/idpbuilder/idpbuilder/main.go:6\nruntime.main\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/proc.go:267\nruntime.goexit\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/asm_amd64.s:1650\nfailed to init node with kubeadm\nsigs.k8s.io/kind/pkg/errors.Wrap\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/errors/errors.go:47\nsigs.k8s.io/kind/pkg/cluster/internal/create/actions/kubeadminit.(*action).Execute\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/actions/kubeadminit/init.go:84\nsigs.k8s.io/kind/pkg/cluster/internal/create.Cluster\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/internal/create/create.go:135\nsigs.k8s.io/kind/pkg/cluster.(*Provider).Create\n\t/home/runner/go/pkg/mod/sigs.k8s.io/kind@v0.23.0/pkg/cluster/provider.go:192\ngithub.com/cnoe-io/idpbuilder/pkg/kind.(*Cluster).Reconcile\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/kind/cluster.go:202\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).ReconcileKindCluster\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:85\ngithub.com/cnoe-io/idpbuilder/pkg/build.(*Build).Run\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/build/build.go:133\ngithub.com/cnoe-io/idpbuilder/pkg/cmd/create.create\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/create/root.go:139\ngithub.com/spf13/cobra.(*Command).execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:983\ngithub.com/spf13/cobra.(*Command).ExecuteC\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1115\ngithub.com/spf13/cobra.(*Command).Execute\n\t/home/runner/go/pkg/mod/github.com/spf13/cobra@v1.8.0/command.go:1039\ngithub.com/cnoe-io/idpbuilder/pkg/cmd.Execute\n\t/home/runner/work/idpbuilder/idpbuilder/pkg/cmd/root.go:30\nmain.main\n\t/home/runner/work/idpbuilder/idpbuilder/main.go:6\nruntime.main\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/proc.go:267\nruntime.goexit\n\t/home/runner/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.21.3.linux-amd64/src/runtime/asm_amd64.s:1650"
Error: failed to init node with kubeadm: command "docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1
Usage:
  idpbuilder create [flags]

Flags:
      --build-name string             Name for build (Prefix for kind cluster name, pod names, etc). (default "localdev")
      --extra-ports string            List of extra ports to expose on the docker container and kubernetes cluster as nodePort (e.g. "22:32222,9090:39090,etc").
  -h, --help                          help for create
      --host string                   Host name to access resources in this cluster. (default "cnoe.localtest.me")
      --ingress-host-name string      Host name used by ingresses. Useful when you have another proxy in front of ingress-nginx that idpbuilder provisions.
      --kind-config string            Path of the kind config file to be used instead of the default.
      --kube-version string           Version of the kind kubernetes cluster to create. (default "v1.29.2")
  -n, --no-exit                       When set, idpbuilder will not exit after all packages are synced. Useful for continuously syncing local directories. (default true)
  -p, --package strings               Paths to locations containing custom packages
  -c, --package-custom-file strings   Name of the package and the path to file to customize the package with. e.g. argocd:/tmp/argocd.yaml
      --port string                   Port number under which idpBuilder tools are accessible. (default "8443")
      --protocol string               Protocol to use to access web UIs. http or https. (default "https")
      --recreate                      Delete cluster first if it already exists.
      --use-path-routing              When set to true, web UIs are exposed under single domain name.

Global Flags:
  -l, --log-level string   Set the log verbosity. Supported values are: debug, info, warn, and error. (default "info")

failed to init node with kubeadm: command "docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6" failed with error: exit status 1

What do you get if you run docker exec --privileged localdev-control-plane kubeadm init --skip-phases=preflight --config=/kind/kubeadm.conf --skip-token-print --v=6 ?

This is what I get which I think should be correct as container does not exist

I see kind deletes them if it fails creating nodes. I opened a PR to make this process much easier to debug. This should help once it gets merged.
https://github.com/cnoe-io/idpbuilder/pull/435
In the meantime, are you able to create kind cluster using kind cli?
Installation should be something like:
# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64
# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-arm64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

Then run kind create cluster
See: https://kind.sigs.k8s.io/docs/user/quick-start/

Good morning, I did another try, I stopped kubernetes in docker desktop and reissued
idpbuilder create. Exactly same behavior as the 1st time, it created

and I was able to copy different details of the container, txt files enclosed
and the process stuck in a loop of WAITING

Labels.txt
log.txt
NETWORK.txt
state.txt

and it continues, I will leave it in this loop until if possible I receive a response from your side

Sorry, I did not see your response that you posted at midnight. So what should I do now? delete manually localdev-control-plane in docker desktop interface 1st then apply the commands
# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-amd64
# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.24.0/kind-linux-arm64
chmod +x ./kind
sudo mv ./kind /usr/local/bin/kind

and it continues, I will leave it in this loop until if possible I receive a response from your side

This seems awfully similar to what I was helping  @cmoulliard  with. He was using Fedora 41 as well. If you still have it running, could you run this command?
kubectl logs -n ingress-nginx deployment/ingress-nginx-controller

Do you see error messages like these?
pthread_create() failed (11: Resource temporarily unavailable)
worker process 41 exited with fatal code 2 and cannot be respawned

If so, the fix was:

Create a file. touch /tmp/cm.yaml
Populate the file with this content:

apiVersion: v1
data:
  allow-snippet-annotations: "true"
  proxy-buffer-size: 32k
  use-forwarded-headers: "true"
  worker-processes: "4"
kind: ConfigMap
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.11.2
  name: ingress-nginx-controller
  namespace: ingress-nginx

Run idpbuilder create --recreate -c nginx:/tmp/cm.yaml

@nabuskey Yes, the command
kind create cluster
went through and cluster was created

and I was able to issue
kubectl get nodes

So then what does this prove and help for running idpbuilder correctly?

So then what does this prove and help for running idpbuilder correctly?

This proves that your system can create kind cluster correctly and we should be able to do the same. Where you get stuck is very likely in the components we install (argocd, ingress-nginx, and gitea).
I think my previous comment here is the next step. https://github.com/cnoe-io/idpbuilder/issues/430#issuecomment-2460336183

OK, so I understand you need to update idpbuilder, how much time can this take?

You don't need a new version of idpbuilder. You should be able to use your existing one.

@nabuskey I did the steps you mentioned ,

created /tmp/cm.yml
ran idpbuilder create --recreate -c nginx:/tmp/cm.yaml
Cluster is created, nginx created but idpbuilder create command still stuck as always

when I run
kubectl get pods -n ingress-nginx
I get

Enclosed 2 files, for describe command
kubectl describe deployments -n ingress-nginx > ingress-nginxDescribe.txt
kubectl describe deployments -n ingress-nginx-controller

ingress-nginx-controllerDescribe.txt
ingress-nginxDescribe.txt
and again, idpbuilder is stuck in a loop

It is a Hyper-VM has 4 CPUs and 8Gig of RAM

Here is the output of both commands lshw and lscpu
lscpu.txt
lshw.txt

Hmm does the node actually reflect available resources? By default, it should make all resources available on the machine.
kubectl describe nodes

As you can see I am in the right context but it is erroring

OK, here is the content of kubectl describe nodes, it seems everythinhg is OK
nodes.txt
I issued
kubectl get namespaces
I got

I issued
kubectl get pods -n argocd
I got

but still cant access the argo site nor gitae

Oh the node has 1 CPU available. And 95% of it is already utilized. Therefore K8s cannot schedule the pod.
Capacity:
  cpu:                1
  ephemeral-storage:  65739308Ki
  hugepages-1Gi:      0
  hugepages-2Mi:      0
  memory:             2269160Ki
  pods:               110

And
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests     Limits
  --------           --------     ------
  cpu                950m (95%)   100m (10%)
  memory             290Mi (13%)  390Mi (17%)
  ephemeral-storage  0 (0%)       0 (0%)
  hugepages-1Gi      0 (0%)       0 (0%)
  hugepages-2Mi      0 (0%)       0 (0%)

So. Why isn't it picking up the number of CPUs you have available.

In docker settings, I increased the CPU to 2 instead of 1, now it shows
Capacity:
cpu:                2
ephemeral-storage:  65739308Ki
hugepages-1Gi:      0
hugepages-2Mi:      0
memory:             2268908Ki
pods:               110
Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource           Requests     Limits

cpu                1050m (52%)  100m (5%)
memory             380Mi (17%)  390Mi (17%)
ephemeral-storage  0 (0%)       0 (0%)
hugepages-1Gi      0 (0%)       0 (0%)
hugepages-2Mi      0 (0%)       0 (0%)
I was able to access the argo site

but the gitea is stuck in init state

Can you share what this command shows please ?
kubectl describe node/<NAME_OF_THE_NODE>

Also, can you please tell me if it is possible to access argo and gitea remotely, such as from my lapto or another desktop inside my network and outside it as I dont want to access the VM and work

Also, can you please tell me if it is possible to access argo and gitea remotely, such as from my lapto or another desktop inside my network and outside it as I dont want to access the VM and work

Yes you can on your laptop using the urls documented here: https://cnoe.io/docs/reference-implementation/installations/idpbuilder/usage#basic-usage
You can also create a cluster on a remote machine and access it from another one using as parameter --host where value could be IP.nip.io or domain.name, etc
Remark: To discuss such questions, can you then contact the idpbuilder members using slack - https://github.com/cnoe-io/idpbuilder?tab=readme-ov-file#community please !

kubectl describe node/localdev-control-plane

I don't see any disk or cpu/memory issue according to
Conditions:
  Type             Status  LastHeartbeatTime                 LastTransitionTime                Reason                       Message
  ----             ------  -----------------                 ------------------                ------                       -------
  MemoryPressure   False   Fri, 08 Nov 2024 10:45:48 +0100   Thu, 07 Nov 2024 11:19:41 +0100   KubeletHasSufficientMemory   kubelet has sufficient memory available
  DiskPressure     False   Fri, 08 Nov 2024 10:45:48 +0100   Thu, 07 Nov 2024 11:19:41 +0100   KubeletHasNoDiskPressure     kubelet has no disk pressure
  PIDPressure      False   Fri, 08 Nov 2024 10:45:48 +0100   Thu, 07 Nov 2024 11:19:41 +0100   KubeletHasSufficientPID      kubelet has sufficient PID available
  Ready            True    Fri, 08 Nov 2024 10:45:48 +0100   Thu, 07 Nov 2024 11:22:21 +0100   KubeletReady                 kubelet is posting ready status

Can you access the following url locally: https://argocd.cnoe.localtest.me:8443/applications

Yes as I said earlier, I am able now to access both, gitea took some more time to get ready that argocd container. However, as agreed with @nabuskey idpbuilder needs to give the right details for not being able to go through

As you know that I was struggling to make local-dev up and running, is it possible to add the different componenets indivisually (Argo Workflows , backstage, Crossplane.........)? If yes, what is the shape of the command and params? Thanks again

Yes. You can install a package individually or several packages as a package is locally a folder containing manifest files + Argocd application(set) file.
Example to install top of the kubernetes cluster (= kind + ingress + gitea + argocd as core packages) the custom package1
git clone https://github.com/cnoe-io/stacks; cd stacks
idp create \
  -p basic/package1

As you know that I was struggling to make local-dev up and running, is it possible to add the different componenets indivisually (Argo Workflows , backstage, Crossplane.........)? If yes, what is the shape of the command and params? Thanks again

If you are talking about the ability to select components to install from the ref impl, it's not possible right now. A stack is a tightly coupled packages that work together, at least for now. To make it more modular, we have to think about how to go about it cleanly. We discussed about this in previous meetings but we haven't reached any conclusions.

Also, can you please tell me if it is possible to access argo and gitea remotely, such as from my lapto or another desktop inside my network and outside it as I dont want to access the VM and work

It's possible with SSH tunneling or any other tunneling mechanisms that map the port to your local loop back interface. For example, for my own development setup, I use SSH and SSM agent.
For example:
ssh -L 8443:localhost:8443 user@host

Then open your browser, go to https://argocd.cnoe.localtest.me:8443

@cmoulliard , I did clone, cd to stacks and tried to run
idpbuilder create -p basic/package1
I get right away (in spite of the fact tha local-dev is running and I can access argocd and gitea, as you can notice also in the 2nd snapshot docker is up and running)

This happens with any other package I tried
idpbuilder create -p ref-implementation
idpbuilder create -p ref-implementation/backstage

@nabuskey I tried
idpbuilder create -p ref-implementation
but getting the same error as above

It should override but if it doesn't you can download it from the release page I linked above. The version should be v0.8.1 when you run idpbuilder version

OK Il will try

I updated to verion 0.8.1, now whateever I run I get

when I run
idpbuilder create --use-path-routing  --package ref-implementation
I get

Ah you need to re-create the cluster because --use-path-routing flag is incompatible with your previous run. So run:
idpbuilder create --use-path-routing --package ref-implementation --recreate

See: https://cnoe.io/docs/reference-implementation/installations/idpbuilder/how-it-works#domain-based-and-path-based-routing

Thanks, but it errors wheather I use --use-path-routing  or not! so what is the difference between a sstandard idpbuilder create and idpbuilder create --use-path-routing?
So if you look at the 1st screen, I issued
idp create -p basic/package1
and even with refernce
idpbuilder create --package ref-implementation

Did you pass the --recreate flag? This flag instructs ipdbuilder to recreate the cluster. Primary used when supplied options do not match.

OK I will do but please tell me what is the bdifference between using -use-path-routing and not using?
2nd, is the exixiting cluster will be deleted and I lose all the config I mad to it?

Path based routing vs domain based routing is documented here.
https://cnoe.io/docs/reference-implementation/installations/idpbuilder/how-it-works#domain-based-and-path-based-routing
If you recreate the cluster, you will lose your config changes. Depending on what config changes you made, there are ways to make it reproducible. What did you change?
If you want to just test something out in a new cluster, you can always create a new one with the name and port flag. E.g --name new-cluster --port 7443.

Thanks, I did recreate with the flag --use-path-routing, in spite of the fact during create I got also and endless loop,
as you can see in the snapshot

I rebooted, it seems that all namespaces, pods are there up and running

but I cant access https://argocd.cnoe.localtest.me:8443/ nor https://gitea.cnoe.localtest.me:8443/
For gitea site I always get

then

for argocd, always getting

@nabuskey please ignore my last email as I recreated the cluster without the flag --use-path-routing , everything went though no loop of waiting and I was able to access argocd and gitea

@nabuskey really very interesting this tool idpbuilder, it seems that there has been a lot of efforts behind and I appreciate it.
I was able to access almost all sites, however, I tried to follow instructiona t
https://github.com/cnoe-io/stacks/blob/main/ref-implementation/README.md
when I access backstage with user1, click on create, I geta a screen where there are no templates as indicated in the readme in spite of the fact I see both, in ArgoCD are deployed

Hey @eliassal, I've been busy with KubeCon. Sorry for the late reply. Are you still having issues?


Update API Reference Links In Index File

Updated per snowy's request. This PR fixes the API doc reference links in the index for the browser demo jsfiddle code.

Closed to fix in another branch.


Problems re-deploying this module to the forge

I am having issues creating the required secure password in the .travis.yml file in order for auto-deployment to the forge to work correctly.
I have done the following:

fresh clone of repo
gem install travis
travis pubkey
travis encrypt -s  (include escaping)
Add the secure string into the .travis.yml file

Having gone through this, including re-creating the tag, many times I am stuck as to why this doesn't work.
You'll see the following issue:
/home/travis/.rvm/gems/ruby-1.9.3-p551/gems/puppet-blacksmith-3.2.0/lib/puppet_blacksmith/forge.rb:51:in `rescue in push!': Error login to the forge https://forgeapi.puppetlabs.com as puppet [400 Bad Request]: {"error":"invalid_grant","error_description":"Username/password do not match"} (Blacksmith::Error)
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/puppet-blacksmith-3.2.0/lib/puppet_blacksmith/forge.rb:42:in `push!'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/lib/dpl/provider/puppet_forge.rb:38:in `push_app'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/lib/dpl/provider.rb:132:in `block in deploy'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/lib/dpl/cli.rb:41:in `fold'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/lib/dpl/provider.rb:132:in `deploy'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/lib/dpl/cli.rb:32:in `run'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/lib/dpl/cli.rb:7:in `run'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/gems/dpl-1.7.9/bin/dpl:5:in `<top (required)>'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/bin/dpl:23:in `load'
	from /home/travis/.rvm/gems/ruby-1.9.3-p551/bin/dpl:23:in `<main>'

@raphink @nibalizer @igalic - any ideas?

Did you link the travis command to the puppet-community repo or yours?

When I run travis pubkey it says Public key for puppet-community/puppet-windows_autoupdate: so i assume so

So are you trying to create it under forge.puppetlabs.com/puppet or forge.puppetlabs.com/liamjbennett? the name: "puppet-windows_autoupdate" part is making it try to publish to the 'puppet' user on the forge.

I want it to go to: forge.puppetlabs.com/puppet

Oh well then you probably just don't have the password, unless igalic gave it to you. Let me try encrypting the password to this repo.

No i don't have it. Thought that might be the issue.

https://github.com/puppet-community/puppet-windows_autoupdate/pull/18

Awesome, thanks. Can you do the same for the other modules, as I want to get them pushed this week?

ya ill script it up

or maybe @raphink and @cmurphy can show me how to use modulesync

Modulesync would be good, but it won't solve the password encryption bit.

see also https://github.com/puppet-community/puppet-community.github.io/issues/5

https://github.com/puppet-community/plumbing/blob/travis/share/travis_secrets and https://github.com/puppet-community/plumbing/pull/1

Maybe I wasn't clear when I said modulesync won't solve the issue. It can deploy .travis.yml with the encrypted strings if they are stored in each module's .sync.yml, but it can't generate the encrypted strings automatically (because that would mean storing the forge password unencrypted in modulesync_configs).

Ok, this sort-of worked.
The module got deployed, which is great :+1:
However some of the matrix jobs failed, which is my bad for not using the standard (extlib) .travis config. Despite that it did highlight some interesting issues.
I can see from extlib that the deployment is triggered upon the success of the ruby 1.9.3 (touchstone) jobs. This has two limitations that I can see:

Limited to one puppet version per ruby version. This is not really an issue for windows modules, because we don't have to care too much about the ruby version but for others this could be.

If one of the jobs fails and it's not the touchstone job then the module can get deployed anyway.

If this is not the appropriate place to discuss this then let me know and I will raise an issue else where.

@liamjbennett so blacksmith was able to handle creating the module? I'm wondering if we can just release using this method or if we need to manually create the module in the forge before blacksmith can work.

Yes it worked fine: https://forge.puppetlabs.com/puppet/windows_autoupdate
There was actually nothing wrong with blacksmith. The forge team actually updated the forge some time ago to auto-create the module when you release the first version via the api.

Awwwwesome.

The problem I have now is the the build appears in error because of the issues noted above.
Should I raise this against the new plumbing project?

Moved to the standard travis.yml file and re-released so closing this issue for now.


Feat: add  accessibility prop to quill

@zenoamaro - Can you merge this?

someone merge this please

Can we have this merged? Please


Fix built-in script path of GDScript to prevent crash

Fix #67779

@vnen PTAL

Seems fine to me!


Navigation from My Forms: including breadcrumbs

User Story:
As a GC Forms form builder, I want to know which form I’m working on as I navigate from the “My Forms” page (since the Settings page gives no indication of a particular form)
https://images.zenhubusercontent.com/315708034/6e0aadc5-02a5-420e-b24a-9cf6015ada3f/navigating_settings_pages.mov
Acceptance criteria:

[ ] Add breadcrumbs to the interface so that as you navigate from My Forms to Settings, it’s clear which Form you’re working on

Thoughts on handling this with a page title vs adding more navigation?
Settings + "Title of your form"


1.6.0

@sladecraven @herveDarritchon
If you have time can pull staging and test your fixes?

@moo-man ok, I'll have a check today and I'll give you my feedback

@moo-man : Also today, this evening (french time)

test ok for me !

[ ] bug css with FF
[ ] bug /credit
[ ] feature drag'ndrop wounds healed with rest

OK for me ( credit button, pay button, "RestRecover" localization)


Init project without src

Hi, is there a way to init a uv project without a src directory and [build-system] in the pyproject.toml?
I currently use rye and to do that I create my project with:
rye init --virtual

But uv looks to work differently. When I run:
uv init --virtual

It doesn't generate the [project] section in the pyproject.toml
I'm forced to keep the [tool.uv.workspace] in the pyproject.toml (or else I get the error error: No ``project`` table found in: ``/Users/<my_user>/<my_project>/pyproject.toml``  when I run uv sync)
I'm not allowed to add dependencies like this:

uv add pydantic

I must do it like this:
uv add --dev pydantic

You can definitely remove the src directory if you don't want to use a src layout, but we do need a build system if you want to use a "real" project. Alternatively, if you want to use a virtual layout, it has to not be a real project (i.e., you can't have a [project] section). It doesn't really make sense to have a [project] section for something that isn't a project.
What are you looking to achieve? Why do you want a virtual layout?

My problem is that the alternative uv init also has some things that don't work well for me, because it adds the src directory and a [build-system] section.
And if I only delete the src  directory, when I run uv add pydanticI get this error:
santiago@192 test_uv % uv add pydantic
Using Python 3.12.4 interpreter at<EMAIL_ADDRESS>Creating virtualenv at: .venv
Resolved 5 packages in 18ms
error: Failed to prepare distributions
  Caused by: Failed to fetch wheel: test-uv @ file:///Users/santiago/Desktop/test_uv
  Caused by: Build backend failed to build wheel through `build_editable()` with exit status: 1
--- stdout:

--- stderr:
Traceback (most recent call last):
  File "<string>", line 11, in <module>
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/build.py", line 83, in build_editable
    return os.path.basename(next(builder.build(directory=wheel_directory, versions=['editable'])))
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 155, in build
    artifact = version_api[version](directory, **build_data)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 494, in build_editable
    return self.build_editable_detection(directory, **build_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 505, in build_editable_detection
    for included_file in self.recurse_selected_project_files():
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 180, in recurse_selected_project_files
    if self.config.only_include:
       ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/config.py", line 806, in only_include
    only_include = only_include_config.get('only-include', self.default_only_include()) or self.packages
                                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 260, in default_only_include
    return self.default_file_selection_options.only_include
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File<EMAIL_ADDRESS>line 995, in __get__
    val = self.func(instance)
          ^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 248, in default_file_selection_options
    raise ValueError(message)
ValueError: Unable to determine which files to ship inside the wheel using the following heuristics: https://hatch.pypa.io/latest/plugins/builder/wheel/#default-file-selection

The most likely cause of this is that there is no directory that matches the name of your project (test_uv).

At least one file selection option must be defined in the `tool.hatch.build.targets.wheel` table, see: https://hatch.pypa.io/latest/config/build/

As an example, if you intend to ship a directory named `foo` that resides within a `src` directory located at the root of your project, you can define the following:

[tool.hatch.build.targets.wheel]
packages = ["src/foo"]
---

And if I delete both I don't get that error, but the directory test_uv.egg-info is created.

How do you plan to structure your projects though? I'm just trying to understand your desired project layout and workflow. If you just want the build to work, you can add this to your pyproject.toml (even if you don't plan to create a test_uv directory):
[tool.hatch.build.targets.wheel]
packages = ["test_uv"]

In my case the root folder would be called test_uv, and the structure inside of it would look like this for example:
.venv
main.py
pyproject.toml
README.md
uv.lock
In a larger case I would maybe have all my python files structured inside an app folder, for example on a FastAPI microservice, where I would also dockerize the proyect. I don't want to create a package or wheel

In my case the root folder would be called test_uv, and the structure inside of it would look like this for example:
.venv main.py pyproject.toml README.md uv.lock
In a larger case I would maybe have all my python files structured inside an app folder, for example on a FastAPI microservice, where I would also dockerize the proyect. I don't want to create a package or wheel

@santigandolfo  In this specific case I believe a work around at the moment is to set this in your pyproject.toml file
[tool.hatch.build.targets.wheel]
packages = ["."]

You can definitely remove the src directory if you don't want to use a src layout, but we do need a build system if you want to use a "real" project. Alternatively, if you want to use a virtual layout, it has to not be a real project (i.e., you can't have a [project] section). It doesn't really make sense to have a [project] section for something that isn't a project.
What are you looking to achieve? Why do you want a virtual layout?

We have to distinguish python libraries and other project. For example, a django project might want to manage its dependencies using uv and does not want a src folder. This project doesn't need any build tool since we don't want to produce a python package at the end. On the other hand, a django reusable package would need to be package for pypi and need a build tool. Hence, depending on the type of project, a build system is needed or not.
Anyway, I consider using a src/ folder as an antipattern in Python. Unfortunately, uv init produces one and install the package  contained in this src/ in the virtual environment as an editable package. Having to fix that manually is actually a no go in adopting uv in all my projects.
Best wishes, Thierry

In my case, I have a src folder:
my-fastapi-app/
    src/
        main.py
    pyproject.toml
    uv.lock
    .venv

And when I execute uv run ruff check, I get this error:
error: Failed to prepare distributions
  Caused by: Failed to fetch wheel: my-fastapi-app @ file:///workspaces/my-fastapi-app
  Caused by: Build backend failed to build wheel through `build_editable()` with exit status: 1

My problem is that the alternative uv init also has some things that don't work well for me, because it adds the src directory and a [build-system] section. And if I only delete the src directory, when I run uv add pydanticI get this error:
santiago@192 test_uv % uv add pydantic
Using Python 3.12.4 interpreter at<EMAIL_ADDRESS>Creating virtualenv at: .venv
Resolved 5 packages in 18ms
error: Failed to prepare distributions
  Caused by: Failed to fetch wheel: test-uv @ file:///Users/santiago/Desktop/test_uv
  Caused by: Build backend failed to build wheel through `build_editable()` with exit status: 1
--- stdout:

--- stderr:
Traceback (most recent call last):
  File "<string>", line 11, in <module>
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/build.py", line 83, in build_editable
    return os.path.basename(next(builder.build(directory=wheel_directory, versions=['editable'])))
                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 155, in build
    artifact = version_api[version](directory, **build_data)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 494, in build_editable
    return self.build_editable_detection(directory, **build_data)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 505, in build_editable_detection
    for included_file in self.recurse_selected_project_files():
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/plugin/interface.py", line 180, in recurse_selected_project_files
    if self.config.only_include:
       ^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/config.py", line 806, in only_include
    only_include = only_include_config.get('only-include', self.default_only_include()) or self.packages
                                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 260, in default_only_include
    return self.default_file_selection_options.only_include
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File<EMAIL_ADDRESS>line 995, in __get__
    val = self.func(instance)
          ^^^^^^^^^^^^^^^^^^^
  File "/Users/santiago/Library/Caches/uv/builds-v0/.tmp0RSYov/lib/python3.12/site-packages/hatchling/builders/wheel.py", line 248, in default_file_selection_options
    raise ValueError(message)
ValueError: Unable to determine which files to ship inside the wheel using the following heuristics: https://hatch.pypa.io/latest/plugins/builder/wheel/#default-file-selection

The most likely cause of this is that there is no directory that matches the name of your project (test_uv).

At least one file selection option must be defined in the `tool.hatch.build.targets.wheel` table, see: https://hatch.pypa.io/latest/config/build/

As an example, if you intend to ship a directory named `foo` that resides within a `src` directory located at the root of your project, you can define the following:

[tool.hatch.build.targets.wheel]
packages = ["src/foo"]
---

And if I delete both I don't get that error, but the directory test_uv.egg-info is created.

The same thing happens to me.
A few days ago I heard about UV thanks to a post by Tiangolo on X. I'm testing it to see if we migrate from pipenv to uv.
It seems that if /src does not exist, the installation of libraries fails.
In my company, projects do not have a /src, but a /app.
It doesn't seem like a correct solution to have to edit pyproject.toml by hand.

You shouldn't need a src directory to use uv -- can you provide an example? E.g., this works without any pyproject.toml changes (it uses an ./app directory): https://github.com/astral-sh/uv-fastapi-example

Thanks for your answers. I'll tell you a little more, clarifying that I'm new to UV.
We currently have projects already managed with pipenv. The Pipfile and Pipfile.lock files are maintained by the pipenv tool, we do not edit them by hand.
I try to operate in the same way, that when running the tool the files are generated correctly (pyproject.toml and uv.lock).
In order to migrate from pipenv to uv, as far as I know, I must first initialize the project by running uv init in the existing project folder. At that moment the /src folder is created and becomes essential for uv to work. The proposed solution requires modifying pyproject.toml by hand, which I don't like very much, I would prefer that the command line execution of uv already provides the option of, for example, initializing with another directory or none at all. This would help run the migration from pipenv automatically on many projects with a script, which I understand is not currently possible due to the need to modify pyproject.toml (although my script could modify pyproject.toml and remove /src but it requires a script smarter and will require further validation).

Aside, this would be resolved by https://github.com/astral-sh/uv/issues/6511.

@AndreuCodina -- To clarify, this works (uv run fastapi dev src/uv_fastapi_example/app/main.py):

As does this (uv run fastapi dev uv_fastapi_example/app/main.py):

Either of these are totally fine. You can also remove the app subdirectory if you want. I only included it there because your example from Discord wanted multiple top-level directories.

I see, but there's something I don't understand. I'll show a case to be more graphical.
I want to create a repository called facedetector, with the next workspaces: api, domain, infrastructure and common.
I'm very flexible in how to do it.
If I execute uv init facedetector to create a new repository, a folder facedetector with a src folder is created, so I imagine I have to create the api, domain, infrastructure and common workspaces under src. Okay, but if I execute uv init api under src, the api workspace has a src under it too, so I'm confused (we have 2 src folders with different meaning).

But if I execute uv init api in the facedetector folder then I'm more confused.

Is src the entry point of the repository and I don't have to have an api workspace?
Please, can you clarify for me what's the architecture you're proposing?
In .NET I always have this structure:
src/
    api/
        main.py
    domain/
    infrastructure/
    common/
tests/

How do you plan to structure your projects though? I'm just trying to understand your desired project layout and workflow.

I think it's a valid and common layout to have your top-level module be a top-level directory in your project. To pick one example, this is how Django is structured. I would expect uv init to create a structure like this:
$ uv init hello
$ tree hello
hello
├── pyproject.toml
└── hello
    └── __init__.py

This is the more natural layout, as when you launch the Python repl at the root of the project it can import your module. Imo, additions to the above basic layout should be behind flags. --add-src, --add-readme, etc.

FWIW, I generally make create-X scripts for every language. Here's my create-python script, which also initializes a fresh git repo with appropriate git ignores, sets up a tests dir, installs basic modules I'll always want (eg. pytest), sets up direnv to automatically activate my venv, etc.
$ create-python hello
...
$ tree hello
hello
├── README.md
├── bin
├── hello
│   └── __init__.py
├── justfile
├── main
├── poetry.lock
├── poetry.toml
├── pyproject.toml
├── pytest.ini
└── tests
    └── __init__.py

I currently use Poetry to manage my Python projects (though I now use uv to manage my user-level .venv). I initialize my projects with (the equivalent of):
poetry init --no-interaction --name=hello --author="$(git config --get user.name)"

That doesn't presume any layout and conveniently lets me specify the author metadata during creation.

This exists now as of v0.4.0. You can run uv init --app to avoid creating a src layout. See: https://docs.astral.sh/uv/concepts/projects/#applications.


Role: degradee/degrader

Degradees/degraders need their own role as all missing aspects of the widely used „bdsmtest.org“ results.
Me for example I feel like a slave, pet and much more just based on being a degradee. My main and most important focus is on humiliation and degradation - this can be a lot of the roles which are stated on fetlife... so it never really feels like the roles „pet“, „slave“ or similar can represent someone who mainly craves for humiliating situations... same for masters who really enjoy / concentrate on humiliation/degradation.
I really hope you might add this role soon. :)

I really want these to be added to, please add then Fetlife


[select] when multiple is true, values can still be deleted although its disable

tdesign-react 版本
new 0.42.0
重现链接
https://tdesign.tencent.com/react/components/select
重现步骤
No response
期望结果
the value should not be deleted
实际结果
No response
框架版本
No response
浏览器版本
No response
系统版本
No response
Node版本
No response
补充说明
No response

the option text need to be disabled too

soga

soga

我来尝试fix

0.42.1 fixed


master-next: DLLImport values should not be hidden

LLVM r322806 defaults to make symbols with non-default visibility be marked
as dso_local. However, there is also an assertion that DLLImport symbols
are not dso_local, since that combination makes no sense. These changes
revealed some problems in Swift's IR linkage for PublicExternal,
HiddenExternal and PrivateExternal SIL linkage. Those mean different things
for definitions vs. declarations.
PublicExternal definitions were marked with DLLExport but with
AvailableExternally linkage. That seems inconsistent. AvailableExternally
symbols are not supposed to be emitted at all.
HiddenExternal and PrivateExternal symbols were using the same visibility
and storage class regardless of whether they were declarations or
definitions. This change fixes that so that those symbols are either hidden
or DLLImport but not both at the same time.
rdar://problem/36683229

I'm going to revise this....

On second thought, I will proceed with this. I had discussed it with Erik a few days ago and was considering making the HiddenExternal/PrivateExternal definitions to not have hidden visibility, but without some specific test cases, I can't convince myself that is correct, especially given Jordan's comment above about this coming up only within a module. This is most conservative fix that I have to get the test passing again. I've already tested it locally but once more wouldn't hurt.

@swift-ci please test and merge

I filed a bug report to investigate more thorough handling of dso_local symbols: https://bugs.swift.org/browse/SR-7016

@swift-ci please test and merge

I don't know what's wrong with the PR testing here. They keep failing for reasons unrelated to my change. I've tested this repeatedly in a local build so I'm going to go ahead and merge this.


Don't Merge! PR real time test for webhook case

Docs Build status updates of commit cb5336f:
:clock10: Pending: waiting for processors (11 builds ahead of you)
:warning: Docs Build is busy, currently there are 11 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit cb5336f:
:clock10: Full build: the average full build time is 5 min(s) 59 sec(s), this is based on the last 586 build(s) for this repository.

Docs Build status updates of commit cb5336f:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details
Dependent Files

docs-ref-conceptual/testing.md
:bulb:Suggestion
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/testing.md

[Suggestion] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Suggestion] Missing attribute: title. Add a title string to show in search engine results.
[Suggestion] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Suggestion] Missing attribute: title. Add a title string to show in search engine results.
[Suggestion] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Suggestion] Missing attribute: title. Add a title string to show in search engine results.

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


LibWeb: Improve grid-template-area parsing and serialization

"foo." should be parsed as "foo ."
Identifiers must only contain "ident code point"s
Each row must have the same number of columns

(this used to cause crashes on https://wpt.live/css/css-grid/grid-definition/grid-inline-support-grid-template-areas-001.html and https://wpt.live/css/css-grid/grid-definition/grid-support-grid-template-areas-001.html)

"a b" "c d" should be serialised as itself (used to be a b, c d)

Overall this brings 108 new passing subtests in WPT's /css/css-grid/ and prevents a crash.
We still need to reject grid-template-area values with non-rectangular areas, but I'll leave that for later.

Side note, can you update the spec link to point to the drafts.csswg.org/css-grid-1 spec?

One thing to note with the draft vs published spec is that we're currently using the published definition of "ident-start code point" which is more permissive than the draft definition, I chose to use the published version because a WPT test expects it.

Code looks good, but IMO this should be factored as two commits:

Moving functions to CharacterTypes.h (and it'd be nice to move all of them not just a couple that you need currently.)
The grid-template-area changes.

Done, I've left the is_specific_character style functions because they're not actually in 4.2 Definitions.
(I personally think they should be inlined as the characters are referenced directly whenever needed in the spec)


Add check for PEM exists for Hive and Livy DAG.

While running hive or livy dag where we use ssh to login into the machine pem file was missing in /tmp folder.
This PR checks whether the file exists or not while copying the pem into /tmp.
If it doesn't exist then it will raise an exception.

I am thinking that the tasks in the DAG could be running on different workers and hence there could be failure as the file system would not be common between them. Can we think if this could be the reason and if yes, how we can resolve this?

when I checked in the worker node the pem file wasn't present. So added the check if the file exists or not.
as you mentioned if a different worker for tasks but I see only one worker node.

if that's the case multiple workers are present then files created in one worker should also be made available in the workers as well.

I am thinking that the tasks in the DAG could be running on different workers and hence there could be failure as the file system would not be common between them. Can we think if this could be the reason and if yes, how we can resolve this?

when I checked in the worker node the pem file wasn't present. So added the check if the file exists or not. as you mentioned if a different worker for tasks but I see only one worker node.

if that's the case multiple workers are present then files created in one worker should also be made available in the workers as well.

yes, currently we have one worker so that may not be the problem. However, I believe there is no sync mechanism available which makes files created on one worker node available on other worker nodes. Even if such a sync existed, there would be delays in sync and we should not rely on a such sync with lags.
Although this change is needed and helps us in raising errors earlier, it still won't solve the problem that the DAG is failing when the copy fails. I believe we need something more to solve this problem of intermittent failures.

I am thinking that the tasks in the DAG could be running on different workers and hence there could be failure as the file system would not be common between them. Can we think if this could be the reason and if yes, how we can resolve this?

when I checked in the worker node the pem file wasn't present. So added the check if the file exists or not. as you mentioned if a different worker for tasks but I see only one worker node.

if that's the case multiple workers are present then files created in one worker should also be made available in the workers as well.

yes, currently we have one worker so that may not be the problem. However, I believe there is no sync mechanism available which makes files created on one worker node available on other worker nodes. Even if such a sync existed, there would be delays in sync and we should not rely on a such sync with lags.
Although this change is needed and helps us in raising errors earlier, it still won't solve the problem that the DAG is failing when the copy fails. I believe we need something more to solve this problem of intermittent failures.

yes, we can merge the copy task into the task which uses PEM and make it one so whenever task on any worker it copies the PEM at that time and then ssh into the machine.

I am thinking that the tasks in the DAG could be running on different workers and hence there could be failure as the file system would not be common between them. Can we think if this could be the reason and if yes, how we can resolve this?

when I checked in the worker node the pem file wasn't present. So added the check if the file exists or not. as you mentioned if a different worker for tasks but I see only one worker node.

if that's the case multiple workers are present then files created in one worker should also be made available in the workers as well.

yes, currently we have one worker so that may not be the problem. However, I believe there is no sync mechanism available which makes files created on one worker node available on other worker nodes. Even if such a sync existed, there would be delays in sync and we should not rely on a such sync with lags.
Although this change is needed and helps us in raising errors earlier, it still won't solve the problem that the DAG is failing when the copy fails. I believe we need something more to solve this problem of intermittent failures.

yes, we can merge the copy task into the task which uses PEM and make it one so whenever task on any worker it copies the PEM at that time and then ssh into the machine.

@pankajkoti I have modified the code to download the PEM as part of the SSH task, so now PEM gets downloaded into the same worker where SSH tasks run.


-- 4

Is your feature request related to a problem? Please describe.

Describe the solution you'd like:

Describe alternatives you've considered:

Additional context:

Closing as incomplete.


Implementing drivers in python

What would you like help with?
I suppose this is already possible by duck typing classes to look like the ones in adbc_driver_manager, but I'm curious what's the general attitude towards implementing new drivers in python. A couple of valid use cases that come to mind are:

cases when there are already available python packages for the backend that wrap other languages and can output arrow. For example, I eventually opted to go with rust in case of datafusion, but I could have instead implemented it in python using datafusion-python. I get that it's not an optimal solution as the end result would only be accessible with python, but it could have accelerated prototype development.
wrappers around existing drivers that augment underlying drivers with some additional functionality. For example, a python driver that wraps a sqlite driver and adds substrait capabilities by translating substrait to sql before invoking actual commands or a driver that's powered by something like sqlglot and does dialect translations in the python layer.

I'm wondering if it might be a good idea to add a dummy python driver implementation to encourage such use cases.

Python wrappers is fine; SQlite already adds a couple of extra methods IIRC.
I'm not sure implementing drivers in Python makes any sense. At that point what you're actually doing is just implementing DB-API, no?

I'm not sure implementing drivers in Python makes any sense. At that point what you're actually doing is just implementing DB-API, no?

sure, I guess that is what I mean, but to be fair it's not just DB-API, right? It's a heavily adbc-flavored DB-API at best. Most of the features why people would look this way is adbc/arrow specific: fetch_arrow, get_objects, partitions, substrait.

The ability to instantly prototype a driver and test it shouldn't be undersold, either (although we could make a project with the boilerplate in Go, C++, and Rust with a few Python tests that might accomplish something similar).

I know this might not be the best comparison, but I'm sort of thinking of python drivers as analogous to the newly added Python DataSource API in pyspark. You could argue that prototyping in java/scala can be just as easy, but it's all about familiarity at the end of the day, right? For pyspark users, python API probably means less hurdles for a prototype. To extend the example to this discussion, if some python system/library is directly using adbc (meaning DB-API with adbc extensions) as a pluggable source, it might be easier to implement some unusual cases directly in python, most likely in the same codebase w/o any additional build steps.

I suppose anyone is free to duck-type themselves as an ADBC driver, I'm mostly just reluctant to expand the scope to include a formal Python API specification. But maybe we should try to intentionally compete with DB-API and/or formalize some of the extensions that we (and others) make to the API.


Update version of checkstyle dep

Updating checkstyle version to 9.3 since version 10+ requires JRE version 11 +
https://checkstyle.sourceforge.io/#JRE_and_JDK

Checkstyle 10.x doesn't support Java 8. So, We should use the latest 9.x (which is now 9.3) version until we change the baseline to Java 11.


Add option to disable impersonation token

Is your feature request related to a problem? Please describe.
jupyterlab-link-share currently extracts the current user's access token and appends it to the URL. In a single jupyterlab instance this makes sense. It gets sketchy in JupyterHub >= 2, where we have permissions for granting users access to each others servers, which the token bypasses and is essentially a token for impersonating the link sharer (only for talking to the current server).
Describe the solution you'd like
Add an option, ideally controllable in server-side config, to omit the token from the URL so that regular JupyterHub access controls are applied instead of sharing a token for impersonation.
There are 3 reasonable links to share in a JupyterHub context:

link to this server, including token for auth (definitely makes sense for standalone servers, sometimes in JupyterHub though deployments may want to prohibit it)
link to this server, no token (shareable link, relies on other auth channels such as JupyterHub auth or a known password)
link to the same file on a shared filesystem, on the user's own server

JupyterLab's built-in 'copy shareable link' does 3, while this extension does 1. But what seems to be missing is 2 (often, copying the URL from the browser will do this. I don't know how often).
In the age of RTC and JupyterHub access permissions, it makes sense to switch between 1 and 2. Some deployments may want only 2 to be allowed.
I see two main options:

single bool flag to switch between 1 and 2 that JupyterHub deployments can pick via config (writing user-settings may be enough)
expose this complexity to users, so they choose at share-time which link to create, and can pick from all 3 (3 only being available when run from a hub).

In some ways, 2. is the simplest, but it puts a decision in the hands of a person who may not have the right information to make it. It's up to the deployment whether 2 will work (do users have permission to access each others' servers?) and 3 (are they even on a shared filesystem?), and the deployment may even want to prohibit 1 by policy (it can't prevent it, technically). Users may well not know whether any of these will work, and the extension has no way to figure any of them out for itself.
Describe alternatives you've considered
Rely on JupyterLab's built-in "copy shareable link", which does the correct thing leaving the token out, but by default uses the user-redirect URL to send users to the same file on their own server (assuming a shared filesystem).
Additional context

Python package version: 0.2.5
Extension version: 0.2.4 (why is this different? I just did pip install jupyterlab-link-share)
Operating System and its version: macOS 13.2

Ping both @balajialg and @yuvipanda - I think this is something we'll want across a bunch of hubs we're concerned with, whether at Berkeley or in collaborative settings like JMTE and CryoCloud.
I'm going to use link-share as-is in Stat159 as discussed yesterday with @ryanlovett and @facusapienza21: we have a controlled environment that's small enough for me to be willing to do this, and given that:

Users still have to initiate the sharing action.
Stopping/restarting their server is annoying but not a major problem.

I think we can deal with it. But this is highly sub-optimal and not at all advisable in any other deployment, so I hope we can get a sharing mechanism with improved security controls soon. It will greatly improve our chances of getting wider adoption/testing of the RTC machinery (I know this has uses beyond RTC, but the existence of RTC is a massive motivator to use these tools).
Thanks all for the great work on this, btw!! It's amazing what this will enable us to do :)


Change authors and add user story

Merge your pull request and I'll update mine with the updated V0.0

Coverage remained the same at 89.093% when pulling 0b2cc05bdd3c033675cdbf3b3a64d42a3ecf00d4 on V0.0_dash into ffff338cb58fdc6e92482ee3bd379155c76295ed on V0.0.


nixos/bluetooth: Allow to enable experimental features

Experimental features are guarded by command line options. This adds an option to enable all experimental features.
Description of changes
Things done

Built on platform(s)

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

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[ ] Fits CONTRIBUTING.md.

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

@fooker I think in current implementation of the module it's possible to enable these via the config without changing the arguments :slightly_smiling_face:
This works for me on bluez 5.75:
  hardware = {
    bluetooth = {
      enable = true;
      settings.General.Experimental = true;
    };
  };

@fooker I think in current implementation of the module it's possible to enable these via the config without changing the arguments 🙂 This works for me on bluez 5.75:
  hardware = {
    bluetooth = {
      enable = true;
      settings.General.Experimental = true;
    };
  };

Oh, I missed that. Thanks.


Invalid auth token with both py libraries for Blynk console 2.0

Hi,
Currently both libraries don't work with the new console 2.0.
https://github.com/blynkkk/blynk-library
https://github.com/vshymanskyy/blynk-library-python
I used the token from:
https://blynk.cloud/dashboard/...
import time
import logging
import BlynkLib

BLYNK_AUTH = 'auth code' #insert your Auth Token here

# initialize Blynk
blynk = BlynkLib.Blynk(BLYNK_AUTH)

# @blynk.on("connected")
# def connect_handler(ping):
#     print('Blynk connected')

# @blynk.on("disconnected")
# def disconnect_handler():
#     print('Blynk disconnected')

print('starting device...')

# main loop that starts program and handles registered events
try:
    while True:
        blynk.run()
except KeyboardInterrupt:
    blynk.disconnect()
    print("Blynk disconnected!")

Error message
    ___  __          __
   / _ )/ /_ _____  / /__
  / _  / / // / _ \/  '_/
 /____/_/\_, /_//_/_/\_\
        /___/ for Python v0.2.0 (Darwin)

starting device...
Invalid auth token

Try this library: [https://github.com/vshymanskyy/blynk-library-python/blob/master/BlynkLib.py]

The problem is you are using the older version of BlynkLib (v0.2.0) with the new auth token from blynk.cloud (v1.0.0). You are obviously installing your blynk for Python through the pip installation in which you should know/realize that it's not gonna be installing the latest version (v1.0.0) instead you got the legacy version because the pip wheel repository is yet to be updated to the latest version of BlynkLib 2.0 for some unknown reasons.
So, to install the latest version, be sure to git clone the blynk-library-python repository  and then perform the manual compilation by:
pi@raspberrypi:~ $ cd blynk-library-python/
pi@raspberrypi:~/blynk-library-python $
pi@raspberrypi:~/blynk-library-python $ sudo python setup.py install
Then you're gonna be using the latest version of BlynkLib.py
cheers from rtxsc

After downloading the file directly the code worked with no issue. Tks for the help!
Blynk Lib


schema-parser and name-resolver types don't work

We're using generateApi with ts-node (ts-node --project ./tsconfig.build.json -r tsconfig-paths/register src/scripts/generateApi.ts) and we're getting some errors resolving SchemaParser and ComponentTypeNameResolver under the hood.

node_modules/swagger-typescript-api/index.d.ts:217:51 - error TS7016: Could not find a declaration file for module './src/schema-parser/schema-parser'. '/home/runner/work/ducargo-backend/ducargo-backend/node_modules/swagger-typescript-api/src/schema-parser/schema-parser.js' implicitly has an 'any' type.
217   | ((schema: Record<string, any>, parser: import("./src/schema-parser/schema-parser").SchemaParser) => string);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

node_modules/swagger-typescript-api/index.d.ts:511:46 - error TS7016: Could not find a declaration file for module './src/util/name-resolver'. '/home/runner/work/ducargo-backend/ducargo-backend/node_modules/swagger-typescript-api/src/util/name-resolver.js' implicitly has an 'any' type.
511     componentTypeNameResolver: typeof import("./src/util/name-resolver").ComponentTypeNameResolver;

Is this a bug in the library?
My generate options:
generateApi({
      output: path.resolve(process.cwd(), '__generated__'),
      spec: {
        openapi: spec.openapi,
        info: spec.info,
        components: spec.components,
        security: spec.security,
        paths: spec.paths,
      } as unknown as Spec,
      httpClientType: 'axios',
      extractRequestBody: true,
      primitiveTypeConstructs: (constructs) => ({
        ...constructs,
        // @ts-ignore
        string: {
          'date-time': 'Date',
        },
      }),
      unwrapResponseData: true,
      extractRequestParams: true,
      extractEnums: true,
      modular: true,
      fileNames: {
        dataContracts: 'api',
        routeTypes: 'routeTypes',
        httpClient: 'httpClient',
      },
    })

(We'd like to keep "noImplicitAny": true in our tsconfig)

I have the same problem. skipLibCheck: true in tsconfig helped me. https://stackoverflow.com/a/39917362


Authenticated successfully but getting invalid or expired token on API call

I authenticated successfully:
$ twurl authorize --consumer-key xxx --consumer-secret xxx
Authorization successful

then, tried to run the following:
$ twurl /1.1/statuses/home_timeline.json
{"errors":[{"code":89,"message":"Invalid or expired token."}]}

Just to clarify, and we don't need to see the whole process, but can you confirm that when you ran twurl authorize, you then went through a PIN-based authentication process involving the web browser and the terminal? And that twurl accounts shows you have a default account and that your .twurlrc file contains account secret and token (please do not share these)

Additionally, if you have a new Twitter Developer Account, do you have access to the v1.1 API (elevated access)

@andypiper Thank you for your reply. It looks like the culprit was the twurlc file; for some reason the default_profile was pointing to the wrong profile. As soon as I changed the default profile the API call worked as expected.

FWIW you can use twurl accounts and twurl set default to fix that if you don't want to edit the hidden file manually. Good to know things are working!


Feature: Google Vertex AI PaLM Support

This adds basic support for both text and chat based models through the Vertex AI API.
Addresses #1240

Code should reflect all of the above changes.
I still have to go in and review examples and documentation.

Tests, examples, and documentation added.
Refactored types and a connection class to separate directories.
I think this is ready for further review.

Would you mind/would you mind if I split this up into two PRs? I think the LLM part and the general auth pieces looks pretty much good (can we call it just GoogleVertexAI rather than GoogleVertexAiTextLLM to be more standard though? And also capitalize AI in the general helper classes?) while the chat model part has a few non-standard things (like context where we've typically used SystemChatMessage) that I'd love to try to standardize.
I'm happy to do the work to split it if you'd like - just don't want to push such a big change directly to the open branch without your ok first!

I have no objection to the name changes for consistency.
I have no strong objections to splitting out the Chat changes if you feel they need further baking, however it does respect the standard of SystemChatMessage to set the context. I added a context field to both the constructor and call options for consistency with Google's model, however providing them as part of messages overrides either of those. See the unit tests (just committed), and I'll provide clarification and usage in the documentation about context and examples.

I have no objection to the name changes for consistency. I have no strong objections to splitting out the Chat changes if you feel they need further baking, however it does respect the standard of SystemChatMessage to set the context. I added a context field to both the constructor and call options for consistency with Google's model, however providing them as part of messages overrides either of those. See the unit tests (just committed), and I'll provide clarification and usage in the documentation about context and examples.

I still think I'd to split it into two just to keep individual PRs compact and focused. I'll start on it now!

Looking forward to release!
(And fine to publish my twitter handle: @afirstenberg, same as github.)
Thanks for your help with this.


chore: Minor refactoring for consistency

getNormalizedZoom -> normalizeZoomValue
roomID -> roomId
various i -> index
Added autofixable rule to ESLint: object-shorthand

We've already went once from roomId → roomID and it ended up breaking clients due to the SW caching issue (you recently asked about it in a different PR), so let's not a do a repeat please :).

Goldfish memory :) But still.. would it be a real problem? We can merge on sunday morning to have as few failures as possible (if any)..

I'm afraid that time of the day or day of the week won't change it much :).

Ok, I was wrong about the roomId change as I mistook with socketId. Sorry about that.


Union for variadic types

There are a lot of situations may occur when we need to define union from several cases.
For example: need to define enum of states.
This would look like:
use Psl\Type as T;

$codec = T\shape([
    // ... rest of fields
    'state' => T\union(
        T\literal_scalar('NEW'),
        T\union(
            T\literal_scalar('APPROVED'),
            T\union(
                T\literal_scalar('REJECTED'),
                T\union(
                    T\literal_scalar('COMPLETED'),
                    T\union(
                        T\literal_scalar('FROZEN'),
                        T\literal_scalar('ERROR')
                    )
                )
            )
        )
    ),
]);

Inferred type would be:
array{id: string, state: "APPROVED"|"COMPLETED"|"ERROR"|"FROZEN"|"NEW"|"REJECTED"}

I guess it would be great to have better solution like:
use Psl\Type as T;

$codec = T\shape([
    'id' => T\string(),
    'state' => T\union_of(
        T\literal_scalar('NEW'),
        T\literal_scalar('APPROVED'),
        T\literal_scalar('REJECTED'),
        T\literal_scalar('COMPLETED'),
        T\literal_scalar('FROZEN'),
        T\literal_scalar('ERROR'),
    ),
]);

I do understand that Psl\Type\Internal\UnionType has only 2 branches: left and right
That's why propose just implement a function with signature:
/**
 * @template T
 *
 * @param TypeInterface<T> $left_type
 * @param TypeInterface<T> $right_type
 * @param TypeInterface<T> ...$others
 * @return TypeInterface<T>
 *
 * @no-named-arguments
 */
function union_of(
    TypeInterface $left_type,
    TypeInterface $right_type,
    TypeInterface ...$others
): TypeInterface { // actually Psl\Type\Internal\UnionType returns here
    ...
}

As alternatives I may guess there is more suitable name for function.
This may be named like literals or one_of or etc.
This function may also be implemented in user land, but I think it would be great to have unified solution inside core of the library.

Want to hear other guys thoughts.
If this would be approved, I may produce PR.
As I can see, this is very light enhancement.

Hm, i think we can allowing extra arguments to Type\union and Type\intersection ( i prefer if these two provide the same API ).
This will also prevent a BC break, in v2.0 we can drop $right and $left and make both union and intersection accept variadic arguments.

🤔 Hmm,  I kept in my that UnionType has left and right branches, therefore function union() takes two arguments to be honest with users.
I was thinking about suggestion to define extra function to prevent boilerplate when we need define union type with a lot of cases.
But, If you think it is alright to expand already existed function - it is fair enough for me

we can have function union(TypeInterface $right, TypeInterface $left, TypeInterface ...$other), UnionType is an internal class, there's no reason to design the public API to match it.

Looks great for me.

I'm on it

By the way, why you want to make union and intersection completely variadic (in v2.0)?
union(string()) - doesn't make sense for me

union(string()) - doesn't make sense for me

it doesn't to me too, but that's solvable via Psl\invariant(Iter\count($types) >= 2, 'at least 2 types are required to create a union.');

union(string()) - doesn't make sense for me

it doesn't to me too, but that's solvable via Psl\invariant(Iter\count($types) >= 2, 'at least 2 types are required to create a union.');

Do you prefer runtime exception instead of statically analysed issue?

You right, first, second and 'rest' sounds more logic, I see it now


Setup test

TravisCI should allow for this to pass (tests are now set to passing).

Nice, looks like TravisCI passed after I changed the results from fail() to return in the test on the main app.


Track plan for preserving unknown fields in Proto3

After much discussion, Google is changing the Proto3 spec to preserve unknown fields, in line with proto2 behavior.
https://github.com/google/protobuf/issues/272
https://docs.google.com/document/d/1KMRX-G91Aa-Y2FkEaHeeviLRRNblgIahbsk4wA14gRk/edit#heading=h.w8dtggryroj4
swift-protobuf should also support this.

Already done #347

Excellent!


openscad: fix lib3mf usage

Description of changes
While lib3mf was provided in buildInputs, it wasn't detected - pkg-config was called on lib3MF name instead of the proper lib3mf. Instead of relying on pkg-config, let's provide these paths directly.
With this patch, 3MF option appears in "File > Export", and it's version is listed in "Help > Library info".
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 214253 run on x86_64-linux 1

2 packages built:

openscad
snis

Or can we just patch the pkg-config invocation?

There is another PR https://github.com/NixOS/nixpkgs/pull/214251 that fixes lib3mf pkg-config file, then I'll be able to just incorporate upstream patch.


NodePool

Can you pull CassandraMetadata -> CassandraFrameMetadata and sink_cluster.rs -> sink_cluster/ changes into a separate PR?

Yeah, I plan on splitting this up a bit. Just opening for some early feedback/check on CI.