Open phvalguima opened 1 month ago
I thought about this issue for a little bit, and I am feeling confused as to how we could implement this feature to the package.
If we were to provide "wrappers" for java commands, it would be difficult to do so because the JRE version change from charm to charm. We could make sure that all charms correctly set JAVA_PATH
, but I doubt that this is that easy. And we would still have the requirements of a single "remote execution API" (= "how do I run this command in the workload container?").
On the contrary, if we used python packages (let's say https://pypi.org/project/pyjks/ for dealing with keystores), those operations are meant to be run on the workload, not on the charm. So we now add some complexity by generating/modifying the keystore on the charm before (binary-)writing it to the workload container.
Java has a lot of features that we now and then need to touch in our charms. Most commonly: managing certs in truststore, keys in keystore or JVM options.
My proposal is to add a new lib here that will be imported by charms needing java-related methods.
We can also use this single-point-of-touch to enforce certain security measures, such as which store encryptions are acceptable.