<div dir="ltr"><div>Hi,</div><div><br></div><div dir="ltr">On Thu, 30 May 2019 at 07:46, gustavo panizzo <<a href="mailto:gfa@zumbi.com.ar">gfa@zumbi.com.ar</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, May 28, 2019 at 06:09:09PM +0200, Victor Seva wrote:<br>
>As already mentioned long ago, We should first "move" the current prosody<br>
>manual config to dsa-puppet.<br>
><br>
<br>
I don't think prosody management should be under DSA, puppet is great if<br>
you have root-level access to the server, which we don't.<br>
<br>
If we take the puppet route, every change will have to go through DSA.<br>
How are we going to troubleshot issues? add new features?<br>
Will DSA own the service then?<br>
<br>
What I like about puppet is that is hands-free, after merging into git<br>
the deploy happends by itself, that part I want to replicate.<br></blockquote><div><br></div><div>Sorry but  management is already through DSA. DSA owns the service.</div><div>And the proper way to ask for changes is via PR to dsa-puppet.</div><div>Changing manually the config was just possible due to the kindness of one nice DSA admin.</div><div><br></div><div>Every time I had to change something it was a pain. We must follow dsa-puppet road.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>Initial work, just adding the prosody module is here [0]. Next step would<br>
the module does not support [1] the puppet version DSA is using<br></blockquote><div><br></div><div>0.4.0 version does [2]</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>be to use the module to generate the configs We need. And modify it if<br>
>something is missing and try to push those changes upstream.<br>
><br>
TBH i'd prefer a module that doesn't hardcode the settings<br>
in its code but takes them from hiera as key values (e.g. $ssl_key: /path/to/file).<br>
but this is only a piece of opinion<br></blockquote><div><br></div><div>We are free to modify the module to our needs. It's a starting point. Nothing was done. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>But, I have no idea how to test this and see what the result would be. I<br>
>would need to investigate how to play with dsa-puppet in a local<br>
>development environment. Any hints?<br>
<br>
again, not owning the deployment makes hard for us to test stuff,<br>
we don't even have access to hiera to do a puppet apply --noop<br>
from a local checkout of the code<br></blockquote><div><br></div><div>Indeed, We have to figure out how to test it. We need to ask dsa for advise.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>[0] <a href="https://salsa.debian.org/vseva/dsa-puppet/commits/vseva/xmpp" rel="noreferrer" target="_blank">https://salsa.debian.org/vseva/dsa-puppet/commits/vseva/xmpp</a><br>
<br>
[1] <a href="https://github.com/mayflower/puppet-prosody/blob/master/metadata.json" rel="noreferrer" target="_blank">https://github.com/mayflower/puppet-prosody/blob/master/metadata.json</a></blockquote><div><br></div><div>[2] <a href="https://salsa.debian.org/vseva/dsa-puppet/blob/vseva/xmpp/3rdparty/modules/prosody/metadata.json">https://salsa.debian.org/vseva/dsa-puppet/blob/vseva/xmpp/3rdparty/modules/prosody/metadata.json</a></div><div><br></div><div>Cheers,</div><div>Victor</div></div></div>