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

[gustavo panizzo]

Hi

On Thu, May 30, 2019 at 06:45:13PM +0200, Victor Seva wrote:
>Hi,
>
>On Thu, 30 May 2019 at 07:46, gustavo panizzo <gfa at zumbi.com.ar> wrote:
>
>> 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.
>>
>
>Sorry but  management is already through DSA. DSA owns the service.
>And the proper way to ask for changes is via PR to dsa-puppet.
>Changing manually the config was just possible due to the kindness of one
>nice DSA admin.

Checking all the bugs filled for the pseudo rtc.debian.org in the BTS
,yeah I read them all, I see you, I see Pocock, I see debacle but 
I don't see DSA, I also read #4908 in RT which has updates mostly from pocock.

I don't see anywhere DSA claiming they own the service, besides if they
own the service, why the RFA ticket?


I don't intend to kick out (like it was possible) DSA from their own
machine, I just want a workflow that works for all people involved.
Lower level changes (firewall, packages, unix-users, sudo, etc) do
require DSA interaction and I plan to send patches to their puppet
repo to accomplish that

But asking DSA, and waiting a round-trip, to enable a module on Prosody,
or change a setting is too much.

here is the simple deploy process I propose

- keep the configuration in salsa
  (https://salsa.debian.org/rtc-team/prosody-configuration)

- changes to the configuration are proposed as MR, there has to be
  a BTS ticket to back the change

- someone else from the team approves the change and merges it
- someone in the debvoip group ssh into vogler.d.o, clones the repo and
  runs make deploy


If we feel confident about this for some time, we can ask DSA for a
dedicated local-user in vogler to perform the last step via a cronjob
We could even run basic tests using salsa's CI against the MR :)

cheers

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