Page MenuHomePhabricator

Implement role based hiera lookups for labs
Closed, DeclinedPublic

Description

Lots of messiness (such as the base::puppet vs puppet vs puppetmaster) one can not easily be fixed in labs due to the fact that prod has role based hiera lookups and labs does not. This needs to be fixed.

@hashar wrote on T136080:

Production has a lot of settings under hiera /hieradata/role/* which are not looked up on labs project. Found that while looking at:

Examples:

hieradata/role/common/mediawiki/appserver.yaml:17:nutcracker::verbosity: "4"
hieradata/role/common/cache/text.yaml:2:cache::cluster: text

The reason are the production vs labs hierarchy being different, the labs one does not have a role_hierarchy:

production

./modules/puppetmaster/files/production.hiera.yaml

:hierarchy:
  - "hosts/%{::hostname}"
  - "regex/%{::fqdn}"
  - "%{::site}/%{::realm}"
  - "%{::site}"
  - "private/%{::site}/%{::realm}"
  - "private/%{::site}"
  - "common"
  - "private/common"

:role_hierarchy:
  - "%{::site}"
  - "common"
  - "private/%{::site}"
  - "private/common"

labs

./modules/puppetmaster/files/labs.hiera.yaml

:hierarchy:
  - "labs/hosts/%{::hostname}"
  - "labs/%{::labsproject}/host/%{::hostname}"
  - "labs/%{::labsproject}/common"
  - "labs"
  - "secret/%{::labsproject}"
  - "private/%{::labsproject}"
  - common
  - "secret/common"
  - "private/common"

That apparently got introduced in May 2015 with 196fd9dbbaa7fb26305b94b53caa3dc6990efad0

Related Objects

Event Timeline

yuvipanda raised the priority of this task from to High.
yuvipanda updated the task description. (Show Details)
yuvipanda added subscribers: yuvipanda, Joe.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 3 2015, 5:08 AM
yuvipanda raised the priority of this task from High to Needs Triage.Dec 3 2015, 8:29 AM
yuvipanda set Security to None.
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptDec 3 2015, 8:29 AM
chasemp triaged this task as Normal priority.Dec 3 2015, 2:22 PM

Is this really difficult to do? I'm very interested in fixing this but not at all sure where to start.

Dzahn added a subscriber: Dzahn.May 26 2016, 12:40 AM

https://wikitech.wikimedia.org/wiki/Puppet_Hiera#Role-based_lookup

It's that "the new parser function/keyword, called role" is something that we (Joe) made ourself and doesn't come from upstream. The question is why that parser function isn't also in labs.

Joe added a comment.May 26 2016, 10:44 AM

The role keyword is used in production to refer to large groups of hosts; we DEFINITELY don't want to have role lookups in labs for the same values we use in production; also, we can't use the "role" keyword in labs as it uses ldap for defining nodes and that function is thought for use at the node scope.

I am honestly unsure when and how this can be useful, and the examples I see cited are just cases in which people forgot to add hiera lookups for labs, which will happen with role-based lookups as well.

You can mimic easily this functionality by adding to the labs hiera something like

- role/%{::_role}

and then adding

$role = abcd

in the ldap definiton of a host.

But, honestly, what would this solve? Remember every new hiera lookup adds complexity where we'd like to reduce it

What this would concretely solve (for me) is projects like tools, where now I have to manually set hiera config on each host of a particular type (/me looks at https://wikitech.wikimedia.org/wiki/Hiera:Tools/host/tools-k8s-etcd-01, https://wikitech.wikimedia.org/wiki/Hiera:Tools/host/tools-k8s-etcd-02, https://wikitech.wikimedia.org/wiki/Hiera:Tools/host/tools-k8s-etcd-03, etc - tons of these). Remember labs isn't just used to test production changes - some of us live here :)

We're also trying to kill all LDAP variables, see T101447

I'm no longer convinced we have to do this. https://phabricator.wikimedia.org/T91990 should cover most of the things we want from this.

EddieGP closed this task as Declined.Apr 13 2018, 11:25 PM
EddieGP added a subscriber: EddieGP.

I agree with the previous comments. Horizons prefix functionality seems to cover about everything this was expected provide. Doing this would neither extinguish the fact that people have to remember setting hiera values for the cloud services, nor would it help to reduce the mess that cloud service hiera currently is. I'm thus boldly declining this.