The use case fits what Puppet calls "environments" (which I think is where production for the default branch comes from as the default puppetmaster environment is called that). I'm unsure whether 3.4 supports all features (documentation is at http://docs.puppetlabs.com/puppet/3/reference/).

I suggest a parameter environments to role::puppet::self à la:

environments => {
  'sandbox-legoktm' => ['instance1', 'instance2'],
  'fix-T4711' => undef,
}

This would create environments at /etc/puppet/environments/sandbox-legoktm and /etc/puppet/environments/fix-T4711, set up the cron jobs for git-sync-upstream accordingly and set the environment for instance1 and instance2 to sandbox-legoktm, with production for all others.

@scfc great teaser. I would like to know more about environments.

Is all that logic already in operations/puppet.git ?

What would be the content of /etc/puppet/environments/sandbox-legoktm , would it be an independent clone of puppet.git where one can cherry pick patches or is it something more complicated.

In T126370#2046565, @hashar wrote:

@scfc great teaser. I would like to know more about environments.

Is all that logic already in operations/puppet.git ?

Unfortunately no :-). That was just a proposal how the different environments could be defined.

What would be the content of /etc/puppet/environments/sandbox-legoktm , would it be an independent clone of puppet.git where one can cherry pick patches or is it something more complicated.

Environments each have (at least) their own manifests and modules directories, so basically multiple clones of operations/puppet. Each could have different cherry-picks & Co.

(NB: Everything untested, based on https://docs.puppet.com/puppet/4.9/environments_suggestions.html & Co.)

There is a related task to add Puppet environments to Beta-Cluster-Infrastructure : T161675: Re-think puppet management for deployment-prep