<div dir="ltr">Hi,<div><br></div><div>Yes, I got the the same conclusion, either write my own charms to try to get the features implemented upstream.</div><div><br></div><div>In a way I think that having some sort of local 'overlay' for the hooks (that get's applied automatically, but doesn't modify the original charms) would make the things easier.</div><div><br></div><div>At this stage the juju ecosystem, despite being quite flexible is not really conductive to external changes. It's pretty much an all-or-nothing approach. It works for well for most deployments, but not when you want to fine-tune (the relatively complex stuff). I do wonder how much need there really is for this fine tuning of the charms, perhaps it's just me ;-)</div><div><br></div><div>kind regards</div><div>Pshem</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, 26 Nov 2015 at 09:34 Peter Sabaini <<a href="mailto:peter.sabaini@canonical.com">peter.sabaini@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 25.11.15 21:29, Pshem Kowalczyk wrote:<br>
> Right,<br>
><br>
> How to you make sure that juju doesn't override my changes? If I had to<br>
> add another mon node (and remove one of the existing ones) the new<br>
> config would be overwritten by the default one.<br>
><br>
> I think the general issue is that I can't tell when particular config<br>
> files will be re-generated.<br>
<br>
Indeed, that only lends itself for configuration outside of the charms'<br>
control. If however you're getting an overlap by a juju-managed config<br>
file your only options are a) get the needed parameter included<br>
upstream or b) fork the charm<br>
<br>
cheers,<br>
peter.<br>
<br>
<br>
<br>
><br>
> kind regards<br>
> Pshem<br>
><br>
><br>
> On Wed, 25 Nov 2015 at 21:58 Peter Sabaini <<a href="mailto:peter.sabaini@canonical.com" target="_blank">peter.sabaini@canonical.com</a><br>
> <mailto:<a href="mailto:peter.sabaini@canonical.com" target="_blank">peter.sabaini@canonical.com</a>>> wrote:<br>
><br>
>     On 24.11.15 23:25, Pshem Kowalczyk wrote:<br>
>     > Hi,<br>
>     ><br>
>     > I'm relatively new to the juju ecosystem. I've built a test/POC<br>
>     > openstack setup using juju charms. Ceph is used as the<br>
>     backend-storage<br>
>     > system for the deployment. Since the production deployment of this<br>
>     > system has to meet some external requirements (particular CRUSH<br>
>     > settings, recovery times etc) I'll have to tune ceph settings a bit.<br>
>     ><br>
>     > The charm itself doesn't seem to have a section to add that<br>
>     information<br>
>     > (some other charms do have that ability). What's the best way of<br>
>     doing it?<br>
>     ><br>
>     > In general case, I've realised that sometimes it would be useful to<br>
>     > have ability to run some actions after juju has finished its<br>
>     > configuration to fine-tune it to particular requirements (without<br>
>     > losing the advantages of using juju for all the dependencies). Is it<br>
>     > possible to do something like that without building my own charms?<br>
><br>
>     We're generally just using "juju ssh", "juju run" and occasionally<br>
>     "juju scp"<br>
><br>
>     Caveat: juju ssh doesn't really handle stdin<br>
><br>
>     cheers,<br>
>     peter.<br>
><br>
>     > kind regards<br>
>     > Pshem<br>
>     ><br>
>     ><br>
>     ><br>
><br>
><br>
>     --<br>
>     Juju mailing list<br>
>     <a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a> <mailto:<a href="mailto:Juju@lists.ubuntu.com" target="_blank">Juju@lists.ubuntu.com</a>><br>
>     Modify settings or unsubscribe at:<br>
>     <a href="https://lists.ubuntu.com/mailman/listinfo/juju" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/juju</a><br>
><br>
<br>
<br>
</blockquote></div>