Portal:Toolforge/Admin/puppet refactor
This page contains some notes on the puppet refactor we are doing for Toolforge, specifically some agreements in how we will be organizing the puppet code.
We agree in refactoring away all the old toollabs namespace in favour of the modern toolforge one.
We also agree in using the modern roles/profiles/classes puppet model:
- a machine has one role
- this role includes one or more profiles
- each profile can include/depend on other profiles, or directly call other classes
Profiles and roles explanation
TODO: review & fill if required.
profile::toolforge::base
This profile contains common class declarations and configuration for all VM instances in the Toolforge project.
Mind that this profile may be compiled for different OS and servers with different roles.
profile::toolforge::grid::base
This profile contains common class declarations and configuration for grid integration, specifically submit nodes (i.e, servers which can somehow submit jobs to the grid).
profile::toolforge::infrastructure
Specific profile for servers which are not meant to be SSH-accesible by end-users of Toolforge.
Refactor examples
Some concrete examples, in this case using the services role.
We have several options for the refactor. For sanity, we should probably follow some practices already established by other of our stuff (i.e, openstack). But still, plenty of options for the resulting organization.
option 1
(AKA: single role, single profile, multiple subclasses)
| Show details |
|---|
|
main services role: role::wmcs::toolforge::services (modules/role/manifests/wmcs/toolforge/services.pp) --> from here include a single 'services' profile main services profile: profile::toolforge::services (modules/profile/manifests/toolforge/services.pp) --> from here call all other classes (aptly, bigbroder, webservicemonitor, etc) services classes: toolforge::aptly (modules/toolforge/manifests/aptly.pp) --> configures & publish 3 aptly repos calling aptly::repo 3 times toolforge::bigbroder (modules/toolforge/manifests/bigbroder.pp) --> does the same as the current toollabs::bigbrother at modules/toollabs/manifests/bigbrother.pp toolforge::service (modules/toolforge/manifests/services.pp) --> does all the othe random stuff for the webservicemonitor, etc ... etc... |
option 2
(AKA: single role, multiple specific profiles)
main services role:
role::wmcs::toolforge::services (modules/role/manifests/wmcs/toolforge/services.pp) --> from here include several profiles
services profile:
profile::toolforge::services (modules/profile/manifests/toolforge/services.pp) --> configure here all the webservicemonitor stuff, etc
aptly profile:
profile::toolforge::aptly (modules/profile/manifests/toolforge/aptly.pp) --> configure here all the aptly stuff, calling directly aptly::repo
bigbrother profile:
profile::toolforge::bigbrother (modules/profile/manifests/toolforge/bigbrother.pp) --> does the same as the current toollabs::bigbrother at modules/toollabs/manifests/bigbrother.pp
...etc...
option 3
(AKA: single role, single profile which includes more specific profiles)
| Show details |
|---|
|
main services role: role::wmcs::toolforge::services (modules/role/manifests/wmcs/toolforge/services.pp) --> from here include a single 'services' profile main services profile: profile::toolforge::services (modules/profile/manifests/toolforge/services.pp) --> from here, include all other more-specific sub-profiles (profile for aptly, profile for bigbrother, etc) aptly profile: profile::toolforge::aptly (modules/profile/manifests/toolforge/aptly.pp) --> configure here all the aptly stuff, calling directly aptly::repo bigbrother profile: profile::toolforge::bigbrother (modules/profile/manifests/toolforge/bigbrother.pp) --> does the same as the current toollabs::bigbrother at modules/toollabs/manifests/bigbrother.pp webservice profile (not to be confused with the main one): profile::toolforge::services (modules/profile/manifests/toolforge/webservice.pp) --> configure here all the webservicemonitor stuff, etc ...etc... |