I have noticed lately some odd behavior… I am utilizing LXD locally and that seems to run fine… but when I switch to the JAAS backed controller and my models therein… I notice 2 things
my actions do not seem so to trigger (When I am logging I do not seem them outputting like I did in LXD) … even with --level=TRACE, I saw a status change but… no logs and no behavior like I expected to occur (I am bumping versions of a npm package)
repeatedly, juju debug-log will start going… then after maybe a minute or so… exits with no error message or warning…
Any ideas? I wiped the model clean which improved some of the behavior where I was seeing difficulty creating EC2 instances via Juju… but then these two things still are present.
on LXD I can confirm my action runs straight away with no problems but ONLY if using the charm directly… instead of via charmhub … logging and all…
could it be on LXD I am on juju 2.9.22 … while JAAS is on 2.9.18 ? or could it be the charmcraft version I used to roll the charm ? 1.5.0 ?
it sounds like something is not quite getting set when packaged to the charmhub…
EDIT: So I am triple checking my work… it appears things are working if I upload the charm directly… next thing to check is to charmcraft pack.. push to the beta channel… and try once more … logging seems to be stable now… no crashes or exists so far with the fresh model and charm rolled locally
EDIT2:
I have now all but confirmed the problem happens somewhere between
because if I just deploy the same exact charm code from my local workspace… things are flawless and I see my behavior expected by the action… soon as I pack it and use the beta channel latest … I immediately return from the action with status completed however that was way way too fast to have worked and again, the version of the application is supposed to increment… which does not happen… leading me to believe … something is up with my charmcraft v1.5.0 packing
I think I recall seeing this issue with debug-log on jaas but thought this to be expected from a public controller, but you are right, it doesn’t make sense.
perhaps next course of action I should file a ticket against … either the charmhub or charmcraft… unclear… will wait a bit if Facundo has advice. meanwhile work around is I have to directly upload charm from my workstation on deploy (which is fine for me but a but trickier for colleagues)
the reason I point to charmhub… or charmcraft… is due to the fact that if I deploy from my local charm… all is well with the action(s)… it is only if I deploy the exact same charm and run the exact same input… the juju versions not changed there… since all of it is working in AWS… it is only presenting the issue when I attempt to load the charm from the charmhub.
just for a sanity check , here’s the output of my juju controllers
Controller Model User Access Cloud/Region Models Nodes HA Version
JAAS prod-vpc me@external (unknown) 2 - - 2.9.18
localhost-localhost* spark admin superuser localhost/localhost 7 9 none 2.9.22
and I can see all is working… my units version number increments (which is the signal that the action completed successfully)
App Version Status Scale Charm Channel Rev Exposed Message
certbot 1.25.0 active 1 mahrio-certbot beta 5 no (update) certbot is associated with mahrio
mahrio 0.0.2 active 1 mahrio 2 no (change-mahrio-version) exiting... 14:56
nginx 1.18.0 active 1 mahrio-nginx beta 5 no (update) NGINX is running 14:55
but if I take the charm from the charmstore (beta channel) … for mahrio … my action just returns immediately and nothing is ever triggered… it just shows successful or the like
Hi, @emcp. Is there still a mismatch between the controller versions in AWS and locally?
The Juju team has done a lot of work on action syntax and support over the past few releases. If you’re running against an older controller, you might try using the older syntax.
I updated the ticket… this is happening even locally on LXD now…
it seems to me according to the response in the ticket that… the actions are NO-OPS if I use the charmhub .charm … whereas if I wire the bundle.yaml file with the local clone of the project… all works great.
I can try the other syntax but. the new syntax works… it just seems to do nothing and then return… if it was the syntax I would imagine it’d complain and error out, but I can try today anyway with the older syntax.