Hi all, I want to modify slightly a template provided by a charm but in no way to alter the upstream code of the charm. I think that by creating subordinate would be sufficient but seems a little bit overkill, can somebody suggest something more “efficient” ?
P.S. It would be ideal if charms offered out of the box a “custom configuration” section for the config files they have under their control.
I can’t think of a nice way to do this in a consistent manner.
The simplest way would be to ssh to the unit and edit the file in the charm directory, but any charm upgrade will wipe that out.
I don’t know your particular use case, but I would like to mention a few things.
Charms are meant to encapsulate best practices around an application, and a shared knowledge base for operators of that app. As such, if you find it doesn’t quite do what you need, then it likely is a gap for other people. And the best way to help them is to get the charm updated.
Sometimes the modification is in conflict with a different thing. And then a subordinate is appropriate so someone can pick the one they want (when it isn’t a simple config that could pick either).
Having a generic “do anything you want” config is usually a misfeature. Yes, it let’s you solve your problem, but nobody else benefits from that solution. It also means things don’t actually work unless you know all the details of how to actually make it work with extensions.
An extreme example would be a base OS charm. With arbitrary extensions it can become anything. But as such its shared utility is very small.
As mentioned, there is always ‘juju ssh’. You can do anything and everything with that. But I would encourage you to make changes to the charm so those improvements create an ecosystem where everyone benefits.
I see you point @jameinel but I can quickly think a couple of cases where the templates have default / sane values but could easily be changed with minimum or no risk at all. A really simple example is the Openstack dashboard charm which does not support the definition of the “Help” URL.
As for your suggestion to go with the upstream charm upgrade, I definitely agree but you know better than me that this is a complex and time consuming process, with (usually) very low priority, until it reaches the end users. To be specific, in my case what I want to do is enable the ability in Openstack to inject a password to a VM. In order to do that, there has to be a config change to nova.conf and in the pipeline for almost a year ( Bug #1755696 “nova-compute charm should be able to enable or dis...” : Bugs : OpenStack nova-compute charm )
