Comment 5 for bug 1489829

Shilpa,

The changes to the status reporting look great. Thanks for making those changes! It's really nice to see useful, informative feedback to the user in `juju status` indicating what they need to do to proceed.

Unfortunately, in my previous review I did miss one case that would be nice to add a status-set for: if the SHA check fails. Currently, the service would keep whatever the last status message was in that case and the user would have to check the logs to see what was wrong.

Regarding the test, in order for Amulet to know what charm it is testing, it has to be run from somewhere within the charm directory. There was a change submitted to Amulet to allow the tests to be run from within the tests/ directory, but I don't know if it was accepted. So, that means that the tests must be run from the root charm folder (/home/charm/charms/trusty/ibm-xlc/ in your case).

The issue that I had with the local.yaml file was that the 00-setup and 10-deploy.py tests were using different locations, with 00-setup using the current directory, whatever it happened to be, while 10-deploy.py was always looking in the tests/ directory. So, your change does address that and it works fine.

Finally, as I mentioned in my reply to your email, having a standalone dev environment is certainly a valid use-case for the compiler, but I do think it limits your options for being able to integrate with other services. As we now have several different compiler / runtime charms like this (Zulu8, XL Fortran, XL C/C++, ibmjavasdk), I wonder if it might be worth looking at using a layer approach for these so that they could satisfy your dev environment use-case and serve as a basis for other services as well. At any rate, that would take some design consideration, and if you think this charm is best served as a standalone dev environment, then we can move forward with that.