Organizing [Composite] Content Views and Delegating Repos/Products to Teams

In my org we have a Linux team (myself included) and lots of product teams. We would like to give each product team one or more repos for them to manage through the lifecycle environments. I am struggling to figure out how to organize this in an easily maintainable and efficient way.

  1. Permissions don’t seem to be granular enough to restrict access to only a repo.
    So each team gets its own product, ok livable.
  2. Machines only get one content view and cannot be assigned repos/producs/whatever from other content views.
    So each team gets its own Content View that contains its repos and a Composite Content View that contains its product Content View AAND all of the OS Content Views (CentOS 6, EPEL 6, Subscription Manager, Katello…)
  3. Each team probably needs activation keys

Where this goes off the rails is number of teams and content view versions… Remember a content view version is a yum repository…

I haven’t even setup one team and I have 598 pulp repos totalling 13G of metadata and 91G in monbodb.

# pulp-admin rpm repo list --fields Id | grep -c Id:
# find /var/lib/pulp/published/yum/master/yum_distributor -type d -name repodata | xargs du -h --total | tail -n1
13G	total
# df -h /var/lib/mongodb/
Filesystem                      Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_mongodb  150G   91G   60G  61% /var/lib/mongodb

What’s going to happen once I start having to create Composite Content Views that contain the OS/EPEL/Katello/Puppet Content Views over and over again?

And what is the benefit of Composite Content Views(CCVs) if you still have to generate the metadata for each of the components even if it’ll never be used? I liked the idea of having the flexibility of a CCV to contain OS/EPEL/Katello and so on Content Views. That way I could refresh each of those on independent schedules. But if I end up w/ 598 pulp repos, maybe I’m better off just using normal Content Views despite the fact that it means a lot of them will contain mostly the same repos.

Team A CentOS 6 - All CentOS 6 repos + Team A’s Repos
Team B CentOS 6 - All CentOS 6 repos + Team B’s Repos
??What if they share?
Team A+B CentOS 6 - All CentOS 6 repos + Team A’s repos + Team B’s repos

Ideally a box would be able to get content from more than one view.

web-prod-1000 might get content from

  • CentOS 6 Base System
  • Team A Content View
  • Team B Content View

Then I could maintain CentOS and each team could promote their own stuff through the lifecycle environments.

What am I doing wrong? How have others solved this?