I know it's been far too long before looking at this -- i apologize sincerely for that.
I wanted to try to address this issue and saw that your bundle deployment ran into an issue deploying `easyrsa` from a ras-pi juju client which of course is arm64. I frequently test against arm64 instances on AWS and don't run into trouble with the deployment -- but I feel like there's a constraint somewhere in the bundle you've deployed which is defaulting the easyrsa unit to have an arch=amd64
I'm making this assessment based on `invalid constraint value: arch=amd64`
I've looked at the current stable charmed-kubernetes bundle and the only constraints on workers is:
`constraints: cores=2 mem=8G root-disk=16G`
the architecture of the juju client (ie -- the terminal you launch the juju deploy from) shouldn't necessarily influence the architecture of the target cloud. I think what's happening is that juju doesn't know it needs to constrain the architecture of your cloud to arm64 machines (if that's what is intended) [1]
When I need to deploy charmed-kubernetes to arm64 only, here's the overlay I deploy with -- effectively forcing juju's hand on deploying the a different architecture rather than letting it have to pick based on the type of cloud you're asking juju to deploy to.
@japbhangra
I know it's been far too long before looking at this -- i apologize sincerely for that.
I wanted to try to address this issue and saw that your bundle deployment ran into an issue deploying `easyrsa` from a ras-pi juju client which of course is arm64. I frequently test against arm64 instances on AWS and don't run into trouble with the deployment -- but I feel like there's a constraint somewhere in the bundle you've deployed which is defaulting the easyrsa unit to have an arch=amd64
I'm making this assessment based on `invalid constraint value: arch=amd64`
I've looked at the current stable charmed-kubernetes bundle and the only constraints on workers is:
`constraints: cores=2 mem=8G root-disk=16G`
the architecture of the juju client (ie -- the terminal you launch the juju deploy from) shouldn't necessarily influence the architecture of the target cloud. I think what's happening is that juju doesn't know it needs to constrain the architecture of your cloud to arm64 machines (if that's what is intended) [1]
When I need to deploy charmed-kubernetes to arm64 only, here's the overlay I deploy with -- effectively forcing juju's hand on deploying the a different architecture rather than letting it have to pick based on the type of cloud you're asking juju to deploy to.
------- ------- ------- ------- ---- load-balancer: control- plane: worker: ------- ------- ------- --
# arm64-overlay.yaml
applications:
easyrsa:
constraints: "arch=arm64 cores=2 mem=8G root-disk=16G"
etcd:
constraints: "arch=arm64 cores=2 mem=8G root-disk=16G"
kubeapi-
constraints: "arch=arm64 cores=1 mem=4G root-disk=16G"
kubernetes-
constraints: "arch=arm64 cores=2 mem=8G root-disk=16G"
kubernetes-
constraints: "arch=arm64 cores=2 mem=8G root-disk=16G"
machines:
"0":
constraints: "arch=arm64"
"1":
constraints: "arch=arm64"
"2":
constraints: "arch=arm64"
"3":
constraints: "arch=arm64"
"4":
constraints: "arch=arm64"
"5":
constraints: "arch=arm64"
"6":
constraints: "arch=arm64"
"7":
constraints: "arch=arm64"
"8":
constraints: "arch=arm64"
"9":
constraints: "arch=arm64"
-------
[1] https:/ /juju.is/ docs/juju/ constraint