Copr integration

[Anthony Towns]

----- Original Message -----
> From: "Mike McLean" <mikem at redhat.com>
> On 10/11/2013 01:09 PM, Miroslav Suchy wrote:
> > Speaking for Copr:
> New hub calls from the current namespace patches: addNamespace,
> removeNamespace, listNamespaces, changeBuildNamespace, getNamespace
> (and more on the way)

changeBuildNamespace?

Would it make sense for that to be addBuildToNamespace and removeBuildFromNamespace instead?

Does it actually make sense to let you remove a build from a namespace? If you have namespaces foo, bar, baz, and build pkg-1.2-3.el6 separately for both foo and bar, doesn't something like:

   changeBuildNamespace pkg-1.2-3.el6 foo baz
   changeBuildNamespace pkg-1.2-3.el6 bar foo

violate the 'uniqueness' constraint for pkg 1.2-3.el6 in foo? At one point it had hash X, now it has hash Y; it could also create conflicts where pkg-1.2-3.el6(from foo, now in baz) is still in foo-build which is meant to be restricted to namespace 'foo' packages.

I think it would make sense to allow

   addBuildNamespace pkg-1.2-3.el6 foo baz

if the build of pkg-1.2-3.el6 in foo is adequate for baz's needs, to save unnecessary rebuilding though.

> 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.

How about tag / namespace inheritance? The use case I'm thinking of is Alice and Bob both want to build a complicated upstream project on top of, say, RHEL 6 in the same koji instance. So Alice wants a build tag alice-foo in namespace 'alice', that inherits from rhel-6.4, and Bob wants bob-foo in namespace 'bob' that also inherits from rhel-6.4. I think that sounds like it would work sensibly.

How are namespaces reflected in all the standard existing calls, like getBuild? If Alice and Bob both do different rebuilds of rsync-3.0.6-9.el6, which is also in rhel-6.4, how do you make sense of:

  $ for tag in rhel-6.4 alice-foo bob-foo; koji latest-pkg $tag rsync; done
  $ koji buildinfo rsync-3.0.6-9.el6

?

> 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.

Being able to promote a scratch build to a legitimate build would be pretty nifty. If 'addBuildToNamespace' existed and validated the uniqueness constraints, I think that would even work. It would also mean that you could make your workflow be "scratch build; test; scratch build; test; scratch build; test; promote to legit build" and not have to bump the revision number every time the tests fail.

> One more thing I should clarify. I'm not planning on having namespaces
> apply to tag names themselves, just to builds.

+1

> 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.

I'd put it down to making it easy to avoid coordination problems. You can do it with %dist tags, but only if you ensure everyone has a unique %dist tag, and doesn't accidentally do builds with the %dist tag set wrong.

> 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.

+1 I'd presume both creating a new namespace and adding builds to a namespace would be controllable by permissions / hub policy too.

Cheers,
aj

-- 
Anthony Towns <atowns at redhat.com>