[Debian-rtc-admin] RFA: rtc.debian.org

[gustavo panizzo]

Hi
On Tue, May 28, 2019 at 06:09:09PM +0200, Victor Seva wrote:
>As already mentioned long ago, We should first "move" the current prosody
>manual config to dsa-puppet.
>

I don't think prosody management should be under DSA, puppet is great if
you have root-level access to the server, which we don't.

If we take the puppet route, every change will have to go through DSA.
How are we going to troubleshot issues? add new features?
Will DSA own the service then?

What I like about puppet is that is hands-free, after merging into git
the deploy happends by itself, that part I want to replicate.

>Initial work, just adding the prosody module is here [0]. Next step would

the module does not support [1] the puppet version DSA is using

>be to use the module to generate the configs We need. And modify it if

>something is missing and try to push those changes upstream.
>
TBH i'd prefer a module that doesn't hardcode the settings
in its code but takes them from hiera as key values (e.g. $ssl_key: /path/to/file).
but this is only a piece of opinion

>But, I have no idea how to test this and see what the result would be. I
>would need to investigate how to play with dsa-puppet in a local
>development environment. Any hints?

again, not owning the deployment makes hard for us to test stuff,
we don't even have access to hiera to do a puppet apply --noop
from a local checkout of the code

>
>Cheers,
>Victor
>
>[0] https://salsa.debian.org/vseva/dsa-puppet/commits/vseva/xmpp

[1] https://github.com/mayflower/puppet-prosody/blob/master/metadata.json


-- 
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333