Copr integration

[Mike McLean]

On 10/18/2013 02:07 AM, Anthony Towns wrote:
> changeBuildNamespace?
> 
> Would it make sense for that to be addBuildToNamespace and removeBuildFromNamespace instead?

I.e. allow builds to occupy multiple namespaces?

It's possible to do so, but we'd have to move the uniqueness constraints
out of the build and rpminfo tables and into some sort of parallel
buildlabel and rpmlabel tables.

I'm not quite grasping the utility however. Though, to be fair, we
haven't exactly sorted out all the use cases. I'll have to think more
about it.

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

Well, to swap two same-NVR builds between two namespaces you'd need a
middle step, e.g.
  foo::pkg-1.2-3.el6 -> NULL
  baz::pkg-1.2-3.el6 -> foo
  foo::pkg-1.2-3.el6 -> baz
Otherwise the first operation would violate uniqueness. Whether
something like this is a good idea is a different question.

You have a good point about the tag condition. We should probably check
for such violations and at least warn about them when changing the
namespace.

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

Right now the main use case for distinct on-null namespaces is for
independent users in a copr-like system to have their own namespace so
they don't have to deal with conflicts with other independent users.

A secondary use case is to simply allow the system to tolerate such
overlaps when they are necessary. For example, your company/project
could have historical nvr/nvra overlaps that you need to be able to
import in parallel.

Note that mixed-namespace builds can coexist in several ways. First, a
null-namespace tag will accept builds of any namespace. Second, a tag
can inherit from a tag of a different namespace. In particular, I expect
it is quite likely that non-default-namespace build tags will inherit
from some base os tag that uses the default namespace.

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

A tag's namespace setting is not inherited. However, when creating a new
tag that has a specified parent, the default namespace is that of the
parent.

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

Interesting, I was about to say that for the first case namespace was
irrelevant (and it is given the current set of patches). However, I
wonder if you're suggesting that foo::kernel and baz::kernel should be
treated as entirely separate packages in terms of showing in such a
query. My gut feeling is we don't want to do that.

In the second case (and really any case where a call accepts a single
build reference that is expected to be singular), namespaces certainly
make for a little complication. First, if you explicitly want a specific
namespace, you can prefix it with ::, e.g. foo::rsync-3.0.6-9.el6. This
is understood by parse_NVR and parse_NVRA, so most calls should just run
with it.

Absent a namespace specification, the default namespace is preferred
when a singular result is expected. Absent that, then the latest one (by
build id) is returned. However, a number of calls pass strict=True to
get_build() which will cause it to error if the build specification is
not unique.

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

Yep, it could be handy, and that capability is certainly something folks
have asked for in the past.