Code as is from the repo. It’s complaining about the entry point not being executable and I am wondering how does it end up checking for that? through permissions?
I have the same entrypoint not executable error as noted above. I’ve made the entrypoint executable in my local directory but that has not resolved anything for me:
rsyring@meld:~/projects/charm-caddy$ chmod u+x src/charm.py
rsyring@meld:~/projects/charm-caddy$ charmcraft pack
Packing the charm
Lint Errors:
- entrypoint: The entrypoint file is not executable: '/root/prime/src/charm.py' (https://juju.is/docs/sdk/charmcraft-analyzers-and-linters#heading--entrypoint)
Aborting due to lint errors (use --force to override).
Failed to build charm for bases index '0'.
@beliaev-maksim Since src/charm.py file must be executable and contain shebang
#!/usr/bin/env python3
in order to work I think this info needs to be explicitly added in to this tutorial. Based on my experience without setting charm.py to be executable charmcraft wan’t pack it and also if shebang is missing application does not start:
2023-06-12T14:13:59.097Z [container-agent] 2023-06-12 14:13:59 WARNING install ./src/charm.py: 1: from: not found
2023-06-12T14:13:59.098Z [container-agent] 2023-06-12 14:13:59 WARNING install ./src/charm.py: 2: from: not found
2023-06-12T14:13:59.100Z [container-agent] 2023-06-12 14:13:59 WARNING install ./src/charm.py: 3: from: not found
2023-06-12T14:13:59.100Z [container-agent] 2023-06-12 14:13:59 WARNING install ./src/charm.py: 4: from: not found
2023-06-12T14:13:59.100Z [container-agent] 2023-06-12 14:13:59 WARNING install ./src/charm.py: 5: import: not found
2023-06-12T14:13:59.100Z [container-agent] 2023-06-12 14:13:59 WARNING install ./src/charm.py: 8: Syntax error: “(” unexpected
2023-06-12T14:13:59.300Z [container-agent] 2023-06-12 14:13:59 ERROR juju.worker.uniter.operation runhook.go:167 hook “install” (via hook dispatching script: dispatch) failed: exit status 2
2023-06-12T14:13:59.301Z [container-agent] 2023-06-12 14:13:59 INFO juju.worker.uniter resolver.go:151 awaiting error resolution for “install” hook
2023-06-12T14:14:03.971Z [pebble] Check “readiness” failure 19 (threshold 3): received non-20x status code 418
2023-06-12T14:14:13.973Z [pebble] Check “readiness” failure 20 (threshold 3): received non-20x status code 418
2023-06-12T14:14:23.971Z [pebble] Check “readiness” failure 21 (threshold 3): received non-20x status code 418
What I’m missing here is a) a definition of “local charm” and b) how to provide credentials for pulling a container image from a private registry.
On Kubernetes there is the concept of an ImagePullSecret to allow authenticating with a container registry. Is there a similar concept with charms, or what do you need to do to make your charm pull an image from a private registry?
Asked around. Long story short: From our point of view, it doesn’t make sense to add information about that in the tutorial. The idea is that a charm is made to be published, and then everything about it goes public. For development you can however use a local image, if you wish.
In other words, Juju Charms are not for application development (i.e. deploying application that are developed in-house), is that what you’re saying?
The Kubernetes Charms tutorial show-cases a containerized fastapi Python application (it could as well be Django, Flask, RoR or anything else someone would develop a Web application in). How such a charm is deployed is explained in Juju | Create a minimal Kubernetes charm, Validate your Charm. It’s neither obvious nor explained, though, what happens with the image that is passed along to the juju deploy command with the --resource option.
IIUC, the image is uploaded to the Juju controller, which manages a local copy of it. In other words, that explains why you wouldn’t use a private container registry for your images, because you upload them directly to your cluster (i.e. the Juju controller).
In my opinion, it would indeed make sense to explain these inner workings in the documentation.
Just a friendly reminder on adding a few words of clarification about what happens to the local charm when it’s being deployed (I suppose uploaded and managed by the Juju controller without any reference to an external image registry).
Providing authentication credentials for private OCI registries
As a side note, it should be possible to provide a JSON or YAML file with an image reference and optionally username and password (i.e. an OCI image resource) to allow the Juju controller to pull an image from a private registry.
I think a note on alternative ways to specify the resource goes beyond the scope of this tutorial (in a tutorial we’re allowed to be opinionated and we don’t have to cover all the options). However:
I’ve just used the examples in your comments to update the reference doc on charm resources:
https://juju.is/docs/juju/charm-resource (you may have to refresh the page to get past cached content)