Handler function is not being called even after changed one of the config values of the config.yaml

[Geetha S]

Hello Team,

We are not seeing that 'create_new_profile' handler function being called when we changed one of the config values from the config.yaml file.

Handler function code snippet : http://pastebin.ubuntu.com/18774917/

When we deployed ibm was base charm using juju 2.0 and try to change default value for config parameter using juju set-config <service-name> <config-parameter>, config-changed hook will trigger but it will not trigger 'create_new_profile' handler function. Here profile_name, was_admin_user, was_admin_pw and profile_path are the config parameters. If we change the value for one of these parameter, create_new_profile handler should be triggered. It's not happening.

Same handler function was working when we deployed using juju 1.25. This issue is happening when we deploy using juju 2.0-beta7.

full reactive handler code: http://paste.ubuntu.com/18811635/

kindly suggest us

Thanks

[Anastasia (anastasia-macmood)]

Could you please clarify:
1. what provider you were using;
2. provide logs, including unit logs.

It may also be helpful to know which version of reactive framework you were using.

[Geetha S (geethas1)]

Hi,

We are using LXD loacl provider.

You can see the full log here : http://paste.ubuntu.com/19884869/

I have ran `juju set-config ibm-was-base profile_name="AppSrv03"` command to change the value for 'profile_name' config option. But it's not triggering the handler function here.

We have deployed this charm using juju-2.0 beta12 version.

[Anastasia (anastasia-macmood)]

Interestingly, in your logs I can see that config-changed exited with status 1.
(2016-07-18 10:37:39 INFO config-changed + exit 1)

Are you 100% sure your functions that hooks call behave? :D

[Anastasia (anastasia-macmood)]

Geetha,

Just to clarify - the value of config parameter 'profile_name' does get changed to the new value (AppSrv03), right? But the handler function does not get triggered?

Could you please confirm that ibm-was-base has the new value? Could you please paste the output of `juju get-config ibm-was-base`?

Thank you for your patience!

[Geetha S (geethas1)]

Hi Anastasia,

Yes, you are right. The value of 'profile_name' config parameter is changed to 'AppSrv03'. But the handler function does not get triggered.

Same handler function I have been tested using juju 1.25. It was working correctly.

Plese find the output of `juju get-config ibm-was-base`: http://paste.ubuntu.com/20006034/

Thanks,
Geetha

[Richard Harding (rharding)]

@cory can you peek at this and see if it's something supported and help break this down into a juju core specific bug if there is something broken in 2.0's handling of the hook exec?

[Cory Johns (johnsca)]

Anastasia,

The "exit 1" in the log is part of the reactive protocol (https://pythonhosted.org/charms.reactive/charms.reactive.bus.html#charms.reactive.bus.ExternalHandler) and in this case just means that the bash portion of the framework is telling the Python portion that none of the handlers should be invoked.

The bash logs are unfortunately chatty, but on line 1039 it is invoking the test check for all the handlers, including create_new_profile, and it looks fine but is clearly returning no handlers to invoke on the next line (1040, "to_invoke="). This seems to imply that the config states are not set, but the logs don't contain a dump of the currently set states (adding `charms.reactive -y get_states` to the top of the reactive code .sh file could verify that).

The fact that the behavior differs between Juju 1.x and 2.x really baffles me, but some thoughts on what could possibly cause that are:

  * Hook invocation changed somehow such that the code that sets up the config.X states doesn't get run at the start of the config-changed hook (this could be caused, for example, by some other file in the hooks/ directory that interferes with it that is somehow ignored in 1.x). However, clearly the rest of the framework is invoked, so this seems unlikely.

  * The invocation or output of config-get might have changed in a way that the reactive framework doesn't handle properly. But this seems like it would cause other, more obvious errors.

  * The states cannot be persisted or read properly. The states are stored in a .unitdata.db sqlite file in the charm directory. If that file cannot be written or read, it could cause the states to show up as empty. This could potentially happen if the pwd was changed (though I thought it used absolute paths using $CHARM_DIR), if the file was removed or overwritten by something else, or if it couldn't be written in the first place. But, again, this would seem to cause far more obvious and catastrophic issues in this or other charms.

I think this is really going to require a deep-dive debugging session, for which I will need access to the full charm layer source and any layers it depends on that are not already published, so that I can deploy it myself and do some debug-hooks to figure out what's going on. Geetha, is that something you can provide me?

[Cory Johns (johnsca)]

Is this the repo in question? https://bazaar.launchpad.net/~ibmcharmers/charms/trusty/layer-ibm-was-base/devel/files

[Geetha S (geethas1)]

I have added `charms.reactive -y get_states` to my reactive code.sh and set config value for profile_name as "AppSrv03".

Here is the full log : http://paste.ubuntu.com/23062169/

Kindly have a look in to Deploy able charm:

https://code.launchpad.net/~ibmcharmers/charms/trusty/ibm-was-base/trunk

Layer charm :

https://code.launchpad.net/~ibmcharmers/charms/trusty/layer-ibm-was-base/trunk

Thanks

[Cory Johns (johnsca)]

After more investigation, it seems that the create_new_profile handler *is* being triggered (line 28051 on the new full log), but is not being invoked. This is actually an issue with the reactive code (ibm-was-base.sh).

Bash handlers (functions decorated with @when, etc) should use "return" instead of "exit". Using "exit" will cause other triggered handlers to be skipped and thus not invoked, which is what is happening here. Moreover, it could be non-deterministic which handlers get skipped and which actually get invoked. So, "exit" in bash handlers should be avoided and you should always use "return" instead.

I'm not sure how this might have worked differently in Juju 1.x, but since these charms use resources, I can't test it on 1.x. But as far as I can tell, it working on 1.x would only be a fluke and should not be relied upon.

[Anastasia (anastasia-macmood)]

@Cory

Since it is in reactive code, could you please target appropriate project with this bug?

It sounds like this bug is Invalid for juju-core. I'll mark it a such once you re-target \o/

[Geetha S (geethas1)]

Hi,

I have tested by changing "exit" with "return" in handler functions, It's working fine now.

@Cory : Thank you for your efforts and help to resolve the issue.

Thanks,
Geetha