Copr integration

[Mike McLean]

On 10/11/2013 01:09 PM, Miroslav Suchy wrote:
> Speaking for Copr:
> Each new project in Copr, should create new namespace in Koji. So if two
> identical NEVRA from two different namespaces would not raise conflict,
> and two identical NEVRA from one namespace would raise conflict, then it
> is everything I need.
> Well - beside some API for namespaces. I need some API to create
> namespace and some API to assign relation between koji tag and namespace.

New hub calls from the current namespace patches: addNamespace,
removeNamespace, listNamespaces, changeBuildNamespace, getNamespace
(and more on the way)

> BTW can you elaborate on relations between namespaces, koji tags and
> build targets and build tags? Especially the last two are kind of fuzzy
> for me.

Associating a namespace with a tag is coming and I expect to post that
early next week, or maybe earlier if I can find the time. The tag
namespace value will serve two major functions.

First, when building, the namespace for the build will be chosen to
match that of the destination tag from the build target used to build.

Second, when tagging a build, the system will require that the build
namespace matches that of the destination tag.

Tags will also be allowed to have a NULL namespace. In that case, builds
for targets with that tag as the destination will go into the default
namespace, but the tag will accept.

Actually, I'm a little unsure about the NULL namespace business. It
might become the future of scratch builds, or it might just go away.

One more thing I should clarify. I'm not planning on having namespaces
apply to tag names themselves, just to builds. Tag names will still be
unique. The associated namespace is just a bit of tag configuration that
controls the two effects listed above. However, I'm somewhat open to
arguments to the contrary.

> And speaking completely general now:
> I find quite useful if NEVRA uniqueness is enforced per koji tag. It
> caught building from incorrect location in Katello and Spacewalk Koji
> for several times.

I'm not quite sure what you mean, but it sounds like this could be
accomplished by creating a new namespace for the tag.

As for building from incorrect location, I'm not sure how the namespace
restriction is going to solve that. However, that sounds like something
that a policy rule could solve. Maybe you could give little more detail?

> But I find quite annoying that I could not build package with the same
> NEVRA in Koji where build other teams and projects (unrelated to mine).
> Those packages was build in different tag. They landed in different yum
> repos. I do not trust that different team, so I do not want to re-tag. I
> just want to build another package with the same NEVRA.

The argument I encountered was that having overlapping NEVRAs in the
wild is confusing. I can certainly see that point, but I still think
there is worth in namespaces. I'd just like to get a clearer argument
for why, other than flexibility for its own sake.

Many of the use cases I can think of that namespaces solve could also be
solved with dist tags or simply release bumps. Seems like a lot of it
boils to to version vanity -- an irrational desire to have the NEVRA be
a particular value.

On the other hand, there probably are cases where the NEVRA needs to be
a particular value. There probably are cases where there are legitimate
reasons for overlap. Since the question was raised, I'd just like to
clarify our reasons.

> Of course - others can have different opinion. So if this can be driven
> by some option in configuration file, then it would be cool. Especially
> whether default namespace will be Foo or Null.

Sure. I built the NVR uniqueness into Koji early on, before it was even
Koji, because NVR overlap was big hassle and could cause confusion, at
least in our use case. I believe my changes are flexible enough to allow
folks to be strict if they want, without requiring them to be.

If folks don't want namespaces, they don't have to add them. I think
I'll even add a DisableNamespaces option in the hub config.