Project

General

Profile

Actions

Task #1158

closed

service policy

Added by Florian Effenberger about 9 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
Team - Q2/2020
Start date:
Due date:
% Done:

0%

Tags:

Description

Every service that is either

  • running on a TDF IP
  • and/or running on a TDF hostname
  • and/or provides productive services for the LibreOffice community

needs to follow a basic service policy, which needs to be drafted, announced and then enforced with a sensible deadline (2-3 months from the time of announcement).

Some ideas for the content:

  • ask for proper documentation
  • for mass-deployable services, have infra work on Salt recipes
  • name at least two responsible parties, with e-mail and one other mean of communication
  • document backup needs
  • document necessity for open ports
  • document necessity for own public IPv4
  • legal compliance

We might consider moving to a two-tier model, where services not following the above rules in due time get moved to a testing environment with restricted incoming and outgoing traffic, and a prominent "-test" in the hostname.

Actions #1

Updated by Florian Effenberger almost 9 years ago

To be revisited during next admin call for more concrete action items

Actions #2

Updated by Florian Effenberger almost 9 years ago

Notes from last admin call:

* List of services, hosts and VMs
* Salt inclusion, infra team access
* Build machines and repositories
Actions #4

Updated by Florian Effenberger over 8 years ago

  • Target version set to Q4/2015
Actions #5

Updated by Florian Effenberger over 8 years ago

  • Subject changed from draft policy for services to service policy
  • Description updated (diff)
Actions #6

Updated by Florian Effenberger over 8 years ago

  • Target version changed from Q4/2015 to Q1/2016
Actions #7

Updated by Florian Effenberger about 8 years ago

Is there any update to this?
Was this discussed again in one of the calls, any further feedback or proposals?
Otherwise I think the ticket description can serve as a good template to distill a first policy out of it (which can easily be amended later on if needed)

Actions #8

Updated by Alexander Werner about 8 years ago

  • Status changed from New to In Progress
  • Tags Salt added

First proposal is deployd in the public infra documentation (salt-states-base.rtfd.org), will be refined more and more.

Actions #9

Updated by Alexander Werner about 8 years ago

Will validate the Policy Proposal together with Norbert's gerrit salting. If the proposal holds, it will become official.

Actions #10

Updated by Florian Effenberger almost 8 years ago

  • Target version changed from Q1/2016 to Q2/2016

Draft has been published and will be put live within the next days/weeks
Please send the latest version to Norbert and Andreas, both of which are board oversight for infra, so they can give comments as well (while Norbert IMHO is in the loop, not sure if Andreas is)

Actions #11

Updated by Alexander Werner almost 8 years ago

Incorporating changes from Jan, finishing touches, then mailing to Andreas and Norbert

Actions #12

Updated by Florian Effenberger almost 8 years ago

Some further thoughts:

  • BoD -> BoD oversight for infra
  • productive service needs to fulfill all legal requirements
  • testing service might get different, non-signed SSL certificate for security reasons (self-signed or different CA)
Actions #13

Updated by Florian Effenberger over 7 years ago

  • Target version changed from Q2/2016 to Qlater
  • Tags deleted (Salt)

Shifting to later due to the infra changes

Actions #14

Updated by Florian Effenberger over 7 years ago

  • Assignee changed from Alexander Werner to Guilhem Moulin

re-assigning to Guilhem in order to clean up Redmine queues
nothing concrete to do at the moment

Actions #15

Updated by Florian Effenberger over 6 years ago

  • Target version changed from Qlater to Q4/2017
Actions #16

Updated by Florian Effenberger about 6 years ago

  • Target version changed from Q4/2017 to Q3/2018

There are actually a few tasks going on in parallel to that effect, so parts of this is done
I'll postpone some bits to Q3

Actions #17

Updated by Dennis Roczek about 6 years ago

Florian Effenberger wrote:
[...]

  • testing service might get different, non-signed SSL certificate for security reasons (self-signed or different CA)

Just want to mention: Nabble is not supporting SSL, see http://support.nabble.com/HTTPS-SSL-urgent-tp7594627p7598046.html

Although they claim that they do not want to support SSL in future (only on their new "Blasma" software, replacing Nabble) (see
http://greghelp.991552.n3.nabble.com/Nabble-and-SSL-https-td4012780.html
) they look into the wildcard certificate service by let's encrypt, see http://support.nabble.com/Let-s-Encrypt-Free-SSL-TLS-Certificates-td7600342.html .

I will keep monitoring.

Just wanted to mention as nobody needs to check double for the same information / results.

Dennis

Actions #18

Updated by Florian Effenberger almost 5 years ago

  • Target version changed from Q3/2018 to Q3/2019

Is something like that in the works? Maybe a topic for an upcoming infra call?

Actions #19

Updated by Florian Effenberger about 4 years ago

  • Target version changed from Q3/2019 to Q2/2020
Actions #20

Updated by Florian Effenberger over 3 years ago

  • Status changed from In Progress to Closed

Is current practice - when a service gets deployed, all these details need to be filled into Salt
No external documentation required so far (plus Salt states public as well), so closing this one for the moment
Should a need come up, can always be re-opened

Actions

Also available in: Atom PDF