What is the way to redeploy a local charm after making changes to it (for fixing issues or adding new changes) irrespective of the status of the deployed unit? I cannot find this on the docs or in the internet search results.
I tried juju refresh <app name> --path dist/<app name>_ubuntu-18.04-amd64.charm but the juju debug-log --tail and the juju status output shows nothing to be happening even after several minutes. So for the time being, I just remove the application and machine and then deploy the charm again. But it is cumbersome and time-consuming.
Also when I build a charm using charmcraft pack, deploy it, make some local changes and build it again, I reliably get an error that says
Lint Errors:
- metadata: Cannot read the metadata.yaml file. (https://juju.is/docs/sdk/charmcraft-analyze#heading--metadata)
even though the metadata.yaml file is obviously there and I haven’t changed it. This gets resolved only after I run charmcraft clean and redo the build from scratch. Is this a known issue and are there any workarounds for dealing with it?
juju refresh should work. (I have the older upgrade-charm in my muscle memory, but I believe that both commands are equivalent.)
It sounds like there might be an issue w/ the metadata.yaml. I’d check file permissions, try on a different box/container, and post the file here, if you can, so that we can take a look at the formatting.
I do not think that there is an issue with metadata.yaml since it does work okay when I do a clean build. Only on a subsequent build, it always complains about being unable to read the metadata.yaml file.
Below are its contents.
name: launchpad
display-name: launchpad
summary: Launchpad web application
maintainer: Guruprasad <redacted email address>
description: |
Launchpad is an open source suite of tools that help people and teams
to work together on software projects.
tags:
# https://juju.is/docs/charm-metadata#heading--charm-store-fields
- network
series:
- bionic
subordinate: false
@facundo, thank you for the help. The lint error about the missing metadata.yaml file is thrown when I rebuild a charm (that was clean built once before) using charmcraft pack. It goes away when I run charmcraft clean before charmcraft pack, but it is a lengthier and a more cumbersome process. Is there something that I can check to investigate why the linter complains about the missing file even though it builds the same charm after running charmcraft clean?
@facundo, yes. You have described the process correctly. In between steps 1 and 2, I often make some changes to the charm code - but definitely not in metadata.yaml.
Today, I made some changes to the charm, built and deployed it as a fresh app after deleting all units and machines from the previous deployments. The deployment process errored out because of a silly mistake that I made and the log lines in juju debug-log said
unit-launchpad-26: 22:51:04 ERROR juju.worker.uniter.operation hook "install" (via explicit, bespoke hook script) failed: exit status 1
unit-launchpad-26: 22:51:04 INFO juju.worker.uniter awaiting error resolution for "install" hook
I fixed the silly error locally, clean built the charm (due to the rebuild issue mentioned earlier in this thread) and ran juju refresh launchpad --path ./dist/launchpad_ubuntu-18.04-amd64.charm. Nothing happened. Since the above log line complained about error resolution, I even ran juju resolved --all after that. But still the updated charm did not get applied/deployed/refreshed/whatever and the logs were still looping on the error that I already know about.
There is nothing in the juju docs that I could find, which tells how to do this very simple thing during the development of a charm. Any help is appreciated!
I cloned the project, switched to the branch, and packed it. It ended up complaining that it misses metadata.yaml, as it’s your case:
Lint Errors:
- metadata: Cannot read the metadata.yaml file. (https://juju.is/docs/sdk/charmcraft-analyze#heading--metadata)
However, I think it’s because the charm tool (which is the one used as backend, as this is a reactive charm) fails to properly build the charm. It gives the following message (but after that it does NOT end in error, which is confusing):
:: build: Unable to locate layer:ols. Do you need to set CHARM_LAYERS_DIR?
@facundo, we build the charm using the Makefile (for example, make build-launchpad) in the charm directory containing the launchpad directory. That actually takes care of cloning the dependencies like layer:ols (which atm, is private but we are working on making it public and open source) and then invoking charmcraft pack.
From this error message, I figured out that CHARM_LAYERS_DIR and CHARM_INTERFACES_DIR are not set to the proper directories when charmcraft pack is invoked. So I added those before the charmcraft pack command in the Makefile and voilĂ , I do not see the metadata.yaml error any more.
But I still do not understand why and how it works when doing a clean build, even when these environment variables aren’t set.
I think the error message from charmcraft pack should state what the actual issue is, instead of something that is totally unrelated to the issue. That would have actually helped save a lot of time here.
I spoke too soon. This only worked when I tried to rebuild the charm without making any code changes. It stopped working as soon as I made some changes.
Can you tell me how you got the error from the actual charm backend so that even I can check that when I run into this error?
While I got a lot of messages, I do not see any message like the one you found
I am running make build-launchpad to build the charm. Full verbose logs at Ubuntu Pastebin. So maybe the error quoted above was only because of not using the Makefile in your case and not directly related to the issue that I am seeing?
Here is the trace of the commands run by the Makefile when building the charm.
Building launchpad...
+ rm -rf launchpad/tmp
+ cp -a tmp launchpad/tmp
+ cd launchpad
+ charmcraft pack
Packing the charm
Lint Errors:
- metadata: Cannot read the metadata.yaml file. (https://juju.is/docs/sdk/charmcraft-analyze#heading--metadata)
Aborting due to lint errors (use --force to override).
Full execution log: '/tmp/charmcraft.log'
Failed to build charm for bases index '0'.
Full execution log: '/home/guruprasad/snap/charmcraft/common/cache/charmcraft/log/charmcraft-20220702-011225.064109.log'
make: *** [Makefile:50: dist/launchpad_ubuntu-18.04-amd64.charm] Error 1
The only additional thing that the Makefile target does is to copy the sibling tmp directory (which contains the layer and interface dependencies from a private repository) before running charmcraft pack.
The build completed successfully when I ran charmcraft clean before charmcraft pack --trace. Trace logs.
I made some changes to charm/launchpad/reactive/launchpad.py and rebuilt the charm and it failed with the error that I have reported in this thread. Trace logs.
2022-07-04 16:12:45.144 :: 2022-07-04 10:42:44.379 :: FileNotFoundError: [Errno 2] No such file or directory: Path('/root/parts/launchpad/build/launchpad/bin')
I see this error in the trace logs before the error complaining about not finding metadata.yaml.
One is that charm is crashing, the other is that Charmcraft is failing to detect that charm crashed and it’s continuing the work, while it should stop.
I opened a bug for the later, let’s focus in the former problem: why the second run makes charm crash with a
FileNotFoundError (produced by os.makedirs, I still don’t understand how).
I tried to reproduce the problem working directly with charm, and I couldn’t. Here it is a question: you set different environment variables in charmcraft.yaml (e.g. CHARM_LAYERS_DIR: tmp/deps/ols-layers/layer), where this tmp directory comes from? thanks!
The tmp folder and its content are created by the charm/Makefile, which is a sibling of the directory containing the charm files, by running make build-launchpad. This command downloads the private layer/interface dependencies and copies them to the charm directory before calling charmcraft pack.
