This message was deleted.

couple people here have played with

profile_service

patterns.

class role::whatever {

  # must be first, controlled by SRE
  include profile::std
  # entry point for service owners
  include profile_whatever

}

I moved away from role:: and profile:: to making top level modules called role_$role and profile_$profile for all profiles and roles

@Lumiere any particular experience or use case that sent you in that direction?

having a massive profile module made it unwieldy, and it make it hard to keep track of who was working where

Interesting. The massive profile was what caused profile_service at least for large complicated services. In that case specifically hadoop. Always wanted to do it for Splunk which is a similar sized problem, but module needed a full rewrite to begin.

yea, we just decided it was worth it to do profile_* across the board, we even use profile_base and profile_$os

Nice. That's a lot farther than anyone, that I know of, has taken it.

our env is similar to what at lot of people see as standard, with some major differences

When i was at Natwest we always had roles and profiles in modules seperate from the control repo and had <department_role> <deparment_profile> because we were all super siloed and didn't trust each other 😂

Cool, thanks, sounds like I'm on the right track, the profile_ and role_ are a variant of this pattern I'd say. I already have too many modules, so not sure I wanna double it with that pattern, but it does make it easier to fine the profiles.

we fixed that by having an org in github enterprise for puppet modules and using r10k to place everything

Yeah, we're on enterprise, currently looking at WhatsaRanjit's idea of puppetfile as code. 100+ devs all writing to the same file seems like a bad time.

we solve that by separating environments, so each smaller dev team gets their own env with their own puppetfile

hmmm, maybe...that'd be a big rewrite of the way things work here.

So right now are you setting commit ids or similar in the Puppetfile?

yeah, tags/release

for me, it's all tags

We used https://www.puppet.com/docs/pe/2019.8/puppetfile.html#declare_content_from_a_relative_control_repo_branch so that it was down to the devs on their modules creating the branches realtive to environment so they never had to edit puppet file

that's clever, it definitely doesn't match our workflow, because we don't have multiple branches in use

looked at that, it might work but need to redo a bunch of stuff here, without saying too much, I'll say I have more than 50 branches in my "deploy strategy"...using strategy very loosely

except in dev dynamics where we allow dyanmic branches for testing only