Feature #6921

Publish our Puppet manifests

Added by intrigeri 2014-03-12 11:12:48 . Updated 2020-01-03 16:40:40 .

Status:
Confirmed
Priority:
Normal
Assignee:
Category:
Infrastructure
Target version:
Start date:
2014-03-12
Due date:
% Done:

0%

Feature Branch:
Type of work:
Sysadmin
Blueprint:

Starter:
0
Affected tool:
Deliverable for:

Description

Ideally, all secrets should be in dedicated, private Puppet modules, and we could publish our Puppet manifests.

Subtasks

Related issues

Related to Tails - Feature #6181: Make it possible to help with sysadmin Resolved 2013-07-23
Related to Tails - Feature #6922: Document how to replicate parts of our infrastructure for local testing In Progress 2014-03-12
Related to Tails - Bug #16958: Fix the design of our Puppet codebase & document design guidelines Confirmed

History

#1 Updated by intrigeri 2014-03-12 11:13:00

  • related to Feature #6181: Make it possible to help with sysadmin added

#2 Updated by intrigeri 2014-03-12 15:14:56

  • blocks Feature #6922: Document how to replicate parts of our infrastructure for local testing added

#3 Updated by intrigeri 2015-01-13 12:57:37

  • Assignee set to bertagaz
  • Target version set to Tails_1.3

Blocks Feature #6922, so setting the same target version and assignee.

#4 Updated by bertagaz 2015-02-09 17:53:52

  • Assignee changed from bertagaz to intrigeri

#7 Updated by intrigeri 2015-02-10 08:55:57

  • Assignee changed from intrigeri to bertagaz

#8 Updated by bertagaz 2015-02-25 09:58:27

  • Target version changed from Tails_1.3 to Tails_1.3.2

Wasn’t completed in time, postponing to the next release.

#9 Updated by bertagaz 2015-02-26 12:03:15

  • Target version changed from Tails_1.3.2 to Sustainability_M1

Targeting for 2.0, as this is a sustainability related ticket.

#10 Updated by bertagaz 2015-02-26 14:56:00

  • blocked by deleted (Feature #6922: Document how to replicate parts of our infrastructure for local testing)

#11 Updated by sajolida 2015-09-22 07:48:38

  • Target version deleted (Sustainability_M1)

#12 Updated by Anonymous 2018-08-18 14:08:10

Was this worked on since?

#13 Updated by intrigeri 2018-08-18 15:02:54

> Was this worked on since?

I’ve been slowly making some progress but we’re not there yet.

#14 Updated by intrigeri 2019-09-22 06:34:42

  • related to Feature #6922: Document how to replicate parts of our infrastructure for local testing added

#15 Updated by intrigeri 2019-09-22 06:44:46

I propose we give up on publishing our full set of manifests, reject this ticket, and instead do this:

  • When we do Bug #16958, if we use the roles/profiles/classes design pattern, most likely we will create new public Puppet classes that include the bits and pieces we already have published. This will de facto move stuff from our private manifests to public repos and provide the higher-level view of how bits and pieces are glued together, that is currently missing for the greatest part in our public Puppet code.
  • Furthermore, while doing Feature #6922, we will surely notice pain points that are caused by information or code being available only in our private manifests. And then we can figure out a good way to solve each such problem, be it via documentation or by moving more code to public Puppet modules (and doing whatever refactoring it takes).

Rationale: IMO, publishing our manifests should not be a goal in itself. It’s a mean to reach other goals, i.e.:

  • Make it easier for our sysadmins to develop improvements and new features locally instead of doing that in our production environment.
  • Make it easier for other folks to contribute to the code that drives our infra, be it by auditing it or improving it.

I believe the alternate strategy I’m proposing will bring us closer to these goals than simply publishing our Puppet manifests. Thoughts?

#16 Updated by intrigeri 2019-09-22 06:45:07

  • related to Bug #16958: Fix the design of our Puppet codebase & document design guidelines added

#17 Updated by intrigeri 2020-01-03 16:40:40

  • Assignee deleted (bertagaz)