Uploaded image for project: 'R10K'
  1. R10K
  2. RK-35

multi-tenancy, with separate hieradata requires workaround.

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Normal
    • Resolution: Fixed
    • Affects Version/s: r10k 1.4.1
    • Fix Version/s: r10k 1.5.0
    • Component/s: None
    • Labels:
    • Template:
    • Story Points:
      1
    • Sprint:
      CODEMGMT 2015-03-25

      Description

      Copied from: https://github.com/puppetlabs/r10k/issues/195

      Pull request to fix this is available here:
      https://github.com/puppetlabs/r10k/pull/295

      I'm experimenting with multi-tenancy, and my use case is a bit unique. This is a different approach to #101 if multiple applications (tenants) have the git-flow release model for puppet code.

      Goal: separate release cycles of applications along the git-flow branches.

      app1 control repo: develop --> test --> staging --> prod
      app1 hieradata repo: develop --> test --> staging --> prod
      app2 control repo: develop --> test --> staging --> prod
      app2 hieradata repo: develop --> test --> staging --> prod

      One way of doing this is locking each to a git hash (#101), but that can be cumbersome and requires everyone be on the same puppet file.

      What I'd like to get working is multi-tenancy with r10k, so that the above workflow could work. If hieradata is inside the same repo as the Puppetfile / aka control repo then this is fine, *but where it collides is separate hieradata repos*.

      Premise

      • every "tenant" would have both a control repo and a hiera data repo.
      • *Hieradata* repo is also released in the git-flow style. (We did this to allow easier hotfixing of data vs code).

      Single Tenant /etc/r10k.yaml

      :sources:
      data:
      basedir: /etc/puppetlabs/puppet/hieradata
      prefix: false
      remote: ssh://git@stash/codo/hieradata.git
      puppet:
      basedir: /etc/puppetlabs/puppet/environments
      prefix: false
      remote: ssh://git@stash/codo/puppetconfig.git

      :purgedirs:

      • /etc/puppetlabs/puppet/environments
      • /etc/puppetlabs/puppet/hieradata

      multitenant /etc/r10k.yaml:

      :sources:
      app1_h:
      basedir: /etc/puppetlabs/puppet/hieradata
      prefix: true
      remote: ssh://git@stash/codo/hieradata.git
      app1_p:
      basedir: /etc/puppetlabs/puppet/environments
      prefix: true
      remote: ssh://git@stash/codo/puppetconfig.git

      :purgedirs:

      • /etc/puppetlabs/puppet/environments
      • /etc/puppetlabs/puppet/hieradata

      config that drives /etc/hiera.yaml

      puppet::hiera_data_dir: "/etc/puppetlabs/puppet/hieradata/%{::environment}"

      I need to set the prefix because that's how multi-tenancy differentiates tenants in the module path and hiera data path. But now I can't just set my environment to "app1_develop" because on the master the environments are "app1_h_develop" and "app1_p_develop" (for hiera data, and 'puppet' control repo respectively).

      It's not valid yaml to get rid of the _p, and _h.

      A rather dirty solution is to have:

      1. environment = `develop`
      2. fact / enc set to `app1`
      3. hiera.yaml data dir set to `$fact _h $environment`
      4. modulepath set to `$fact _p $environment`

      ... but that's quite kludgy.

      @adrienthebo does this make sense or am I missing something? If it makes sense would a feature to implement *prefix_name* solve this? As follows:

      :sources:
      app1_hieradata:
      basedir: /etc/puppetlabs/puppet/hieradata
      prefix: true
      prefix_name: app1
      remote: ssh://git@stash/codo/hieradata.git
      app1_puppetconfig:
      basedir: /etc/puppetlabs/puppet/environments
      prefix: true
      prefix_name: app1
      remote: ssh://git@stash/codo/puppetconfig.git

      :purgedirs:

      • /etc/puppetlabs/puppet/environments
      • /etc/puppetlabs/puppet/hieradata

      If i set /etc/r10k.yaml to have two sources with the same name, it won't create both as it obviously has duplicate keys.

      Do you have a better idea to solve this?

        Attachments

          Activity

            jsd-sla-details-panel

              People

              • Assignee:
                Unassigned
                Reporter:
                brettswift Brett Swift
              • Votes:
                0 Vote for this issue
                Watchers:
                2 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: