@tmihoc I’m totally game. I’m writing a translation on this for LXD as we speak and testing it for tomorrows workshop.
How can I transfer the material to you?
Pro tip: Try to make your
__init__method as lightweight as possible. The reason is because a charm is a stateless application, so the class is reinitialised on every event, so a heavy init could result in high load calls.
Not sure what ‘high load calls’ means here, and the whole paragraph is a bit ambiguous.
I think the ‘keep your __init__ light’ is a good principle, but I’d argue for it differently.
Maybe I would instead recommend: use __init__ to hold references (pointers) to other objects (relation wrappers for example) or immutable state only: mutable state is confusing in a charm’s context, because, as you say, a fresh instance will be created at each hook execution, so the state’s lifetime is bound to that of a single event handler (or several, if you factor deferrals in, but let’s say only one ‘juju event’).
I don’t think charm runtime (including __init__ runtime) is ever a realistic concern, given how little time charm execution takes compared to the broader Juju thing. So long as the charm takes under ~30 seconds to return, you’re fine.
1 Like
I had to use --force flag to make this work. Here is what I have in the logs
2023-02-23 19:44:19.698 :: 2023-02-24 02:44:18.921 - entrypoint: The entrypoint file is not executable: '/root/prime/src/charm.py' (https://juju.is/docs/sdk/charmcraft-analyzers-and-linters#heading--entrypoint)
2023-02-23 19:44:19.698 :: 2023-02-24 02:44:18.921 Aborting due to lint errors (use --force to override).
2023-02-23 19:44:20.955 Failed to build charm for bases index '0'.
2023-02-23 19:44:20.963 Traceback (most recent call last):
2023-02-23 19:44:20.964 File "/snap/charmcraft/1171/lib/charmcraft/commands/build.py", line 376, in pack_charm_in_instance
2023-02-23 19:44:20.964 instance.execute_run(cmd, check=True, cwd=instance_output_dir)
2023-02-23 19:44:20.964 File "/snap/charmcraft/1171/lib/craft_providers/lxd/lxd_instance.py", line 289, in execute_run
2023-02-23 19:44:20.964 return self.lxc.exec(
2023-02-23 19:44:20.964 File "/snap/charmcraft/1171/lib/craft_providers/lxd/lxc.py", line 329, in exec
2023-02-23 19:44:20.964 return runner(final_cmd, **kwargs) # pylint: disable=subprocess-run-check
2023-02-23 19:44:20.964 File "/snap/charmcraft/1171/usr/lib/python3.8/subprocess.py", line 516, in run
2023-02-23 19:44:20.964 raise CalledProcessError(retcode, process.args,
2023-02-23 19:44:20.964 subprocess.CalledProcessError: Command '['lxc', '--project', 'charmcraft', 'exec', 'local:charmcraft-demo-api-charm-258049-0-0-amd64', '--cwd', '/root/project', '--', 'env', 'PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin', 'CHARMCRAFT_MANAGED_MODE=1', 'charmcraft', 'pack', '--bases-index', '0', '--verbosity=brief']' returned non-zero exit status 2.it says that there are some linting issues
have you checked that code is fine?
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?
maybe by shebang ?
do you have it included in your python file? also might worth to check permissions
Why are not use charmcraft init?
I had it added and I chmod u+x the file. This seems to resolve the issue.
1 Like
we had to revert this idea because it was too confusing for the tutorial
@sergiusens, does charmcraft require executable python files in order to pack it? or maybe the issue is somewhere else and we just see a side effect?
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'.
Anyone have further ideas?
I ended up finding the answer at: https://github.com/canonical/charmcraft/issues/907#issuecomment-1289249016. It has to do with the packer not detecting that the file’s permissions have changed.
Option #1
charmcraft clean
charmcraft pack # Works
Option #2
$ touch src/charm.py
4 Likes
There is a minor typo in the doc having the word class twice in a row:
1 Like
@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
1 Like
Thanks, will update! (Just ran into this issue myself earlier today.)
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?
Added a note to clarify (a) (local charm). Will look into (b) (how to provide credentials for pulling a container 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.
Based on my investigation: No, there is currently not.
The --resource flag accepts 3 types of arguments:
- a charm revision number (if the charm is on Charmhub)
- a path to a local file
- a link to a public OCI image
I will update the docs to make this clearer – and thanks for bringing it up.