Summary
Even after deprecating the puppet master command in favor of Puppet Server, user-facing strings still contain puppet master terminology across help text, docs, API references, and comments.
Supporting Context
- Source PR summary provided by user:
puppetlabs/puppet PR #9572
- Original upstream transition commit for
master -> server terminology/section direction:
- Commit: a2ea0d6
- Subject:
(PUP-10669) Server settings section
- Date:
2020-10-13
Scope to Include (from PR summary)
- CLI help text in app classes (
agent, apply, device).
- Face descriptions/summaries (
catalog, facts, node clean, plugin, report).
- Indirector terminus descriptions and indirector face text.
- Reference docs (
configuration, function, indirection, report, type).
- API endpoint docs (
certificate, certificate_request, certificate_revocation_list, certificate_status, environments, report).
- Internal docs (
indirector.md, profiling.md).
- Man pages (troff and markdown generated output).
- Localization template (
puppet.pot).
- Relevant code comments where user-facing wording appears.
Explicit Exclusions (from PR summary)
- Beaker role identifiers using
master in acceptance tests.
- Specs that intentionally cover backwards compatibility for
master run mode.
- Runtime code preserving
:master compatibility (run_mode, settings aliases, route compatibility).
- Command migration examples where
puppet master --compile should become puppet catalog compile.
Proposed OpenVox 9 Change
- Apply a user-facing terminology sweep: replace
puppet master with Puppet server / Puppet Server as appropriate.
- Keep runtime compatibility code unchanged unless separately tracked by removal issues.
Compatibility / Risk
- Low functional risk (documentation/help/manpage/localization string updates only).
- Moderate review risk due to broad file touch surface.
Implementation Notes
- Keep substitutions context-aware (
product name vs generic server term).
- Run doc/manpage generation checks after string updates.
- Avoid changing framework/test role names or compatibility identifiers that are not user-facing terminology.
Acceptance Criteria
- User-facing references to
puppet master are updated across the documented scope.
- Excluded compatibility/test/runtime areas remain untouched.
- Help/man pages/docs render correctly and keep existing behavior.
Suggested Tests
- Verify
puppet agent --help, puppet apply --help, puppet device --help.
- Verify
puppet plugin --help, puppet catalog --help, puppet facts --help, puppet report --help, puppet node --help.
- Verify man pages render (
man puppet-agent, man puppet-catalog, etc.).
- Run existing tests to confirm no behavior regressions from string-only changes.
Summary
Even after deprecating the
puppet mastercommand in favor of Puppet Server, user-facing strings still containpuppet masterterminology across help text, docs, API references, and comments.Supporting Context
puppetlabs/puppetPR#9572master->serverterminology/section direction:(PUP-10669) Server settings section2020-10-13Scope to Include (from PR summary)
agent,apply,device).catalog,facts,node clean,plugin,report).configuration,function,indirection,report,type).certificate,certificate_request,certificate_revocation_list,certificate_status,environments,report).indirector.md,profiling.md).puppet.pot).Explicit Exclusions (from PR summary)
masterin acceptance tests.masterrun mode.:mastercompatibility (run_mode, settings aliases, route compatibility).puppet master --compileshould becomepuppet catalog compile.Proposed OpenVox 9 Change
puppet masterwithPuppet server/Puppet Serveras appropriate.Compatibility / Risk
Implementation Notes
product namevsgeneric server term).Acceptance Criteria
puppet masterare updated across the documented scope.Suggested Tests
puppet agent --help,puppet apply --help,puppet device --help.puppet plugin --help,puppet catalog --help,puppet facts --help,puppet report --help,puppet node --help.man puppet-agent,man puppet-catalog, etc.).