Page MenuHomePhabricator

Create staging cluster
Closed, DeclinedPublic

Description

Task assignee: This task is effectively assigned to Chad, Mukunda, Tyler, and Yuvi.

Tracking task for all the things needed to create the staging cluster.

See the etherpad of the list of machines we want to replicate from production (which are broken into subtasks here, please add more subtasks if anything is missed).

Related Objects

StatusSubtypeAssignedTask
DeclinedNone
DeclinedNone
Resolvedthcipriani
Resolvedfaidon
DeclinedNone
DeclinedNone
ResolvedNone
Resolveddemon
Resolvedmmodell
DeclinedNone
DeclinedNone
DeclinedNone
Resolveddemon
Declinedmmodell
DeclinedNone
DeclinedNone
Resolved yuvipanda
DeclinedNone
DeclinedNone
DeclinedNone
DeclinedNone
DeclinedNone
DeclinedNone
DeclinedNone
Resolvedthcipriani
DeclinedNone
DeclinedNone
DeclinedNone

Event Timeline

greg created this task.Feb 5 2015, 6:19 PM
greg raised the priority of this task from to Medium.
greg updated the task description. (Show Details)
greg added a project: Staging.
greg added subscribers: greg, yuvipanda, mmodell, demon.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 5 2015, 6:19 PM
greg set Security to None.Feb 26 2015, 10:19 PM
greg added a subscriber: thcipriani.
greg updated the task description. (Show Details)Feb 26 2015, 10:23 PM
greg updated the task description. (Show Details)Mar 6 2015, 5:43 PM

Staging project

Aside from "creating all server" what does "done" look like?

Knowns

  • Same OS: Servers created should match production, e.g. use same server OS Trusty or Precise, being bleeding edge slows down things down on packaging, seemingly.
  • Same Roles: Puppet roles that diverge between labs and production should be unified into a single role that works for both
  • Different Parameters: Puppet classes requiring ::config classes or additional parameters should be parameterized and configured through yaml
  • No Manual Steps: Should be able to kill and recreate servers easily

Known unknowns

  • Should we continue to use LDAP for puppet role config, or use the new hiera_include('classes') and stash all yaml for individual servers in yaml files named for the host? What repo do those go in? puppet/operations seems wrong.
  • How flexible are any of the "Knowns" when they become major blockers? Namely the "No manual steps" piece—there are still manual steps in production—working to eliminate these steps will create some blockers.

Unknown unknowns

Just how deep does the rabbit hole go?

What to do when the goals conflict?

I think ideally we should strive to make it automatic in *both* prod and staging :D but in cases when that isn’t desired (having puppet thrash around dbs does sound scary), we should stick to ‘same as prod, assuming prod has good reasons, if they do not, change prod as well, and then same to prod'. also ‘when they do have good reasons, document them, see if we can turn it into a script that we then put it in the puppet repo'

T85279 for LDAP vs hiera. I definitely don't think we should use hiera classes for everything.

greg changed the status of subtask T91545: Create staging-db* (databases) from Open to Stalled.Apr 29 2015, 4:37 PM
demon closed this task as Declined.Apr 26 2016, 4:15 PM
Restricted Application removed a subscriber: Liuxinyu970226. · View Herald TranscriptApr 26 2016, 4:15 PM
Phabricator_maintenance renamed this task from Create staging cluster (tracking) to Create staging cluster.Aug 13 2016, 9:33 PM