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.
- Permissions don’t seem to be granular enough to restrict access to only a repo.
So each team gets its own product, ok livable. - 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…) - 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:
598
# 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?