Package ownership

Development
#1

We’re evaluating Pulp at my company and we have a requirement that I wanted to ask about. We have shared repos that various teams can upload content to and we want to enforce who can upload what packages by the package name.

So to illustrate, say you have an epel-like rpm repo that is shared by various teams. We don’t want the emacs team to be able to add packages to it with the name “vim” regardless of the version/arch/release/etc.

I’m not familiar with Pulp’s RBAC model. Is this something that Pulp can handle or will be able to handle? Or maybe it’s something we could contribute or possibly have a hook for? We’d need this for pulp_deb and pulp_rpm.

Thanks.

3 Likes
#2

I do not see a way to configure such a thing in the current versions of Pulp. Please help me to understand better. You want to be able to specify whether a user can upload packages whose names match “vim.*” as a regex into a specific repository?

Kudos for pluging the editor wars…

4 Likes
#4

Yes, that’d work I think. I had imagined that the code would check on the Package name attribute when a user attempts to add it to the repository. But a regex would be more powerful.

#5

To add a bit to David’s request - ideally, whomever uploads the first vim package would “own” that package name within that repo. Thus, no other user could upload a newer version of vim and potentially introduce a breaking change.
Using a regex is a good idea. Manually managing such a regex could get cumbersome (with multiple users and dozens of package names), but it could build automatically over time as more packages are uploaded.
Thanks for the insight.

2 Likes
#6

my 2c

On Galaxy we resolve this by introducing namespaces, so content is served through namespace/package the creator of the namespace is the owner and the only one that can upload new packages to that namespace.

For that we use django model permissions.

1 Like
#7

That’s interesting. I’m wondering if this concept can be moved to Pulp or supported in other plugins so that we can use it.

#8

A couple of thoughts.
I am unaware of any way to drive this through pulp directly, however some alternate idea’s.

  1. Provide dedicated repositories, creating/managing repos is fairly cheap, and allows for clean isolation between packages and their dependants.
  2. Drive this through vcs/ci.

In your suggested model, how do you account for package dependencies, and if package a and package b are owned by different people but they both depend on package c?

4 Likes
#9

And you can still use repo to repo copy to create a “combined view” repo that contains everything. OTOH, with rpm/deb it’s quite easy to just hook up the consuming machines to multiple repos.

1 Like