Copr integration

[Anthony Towns]

----- Original Message -----
> From: "Mike McLean" <mikem at redhat.com>
> 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? 

Yeah, that's what I was thinking.

'addBuildNamespace' might also make more sense for the null to namespace step; ie

  def addBuildNamespace(build, ns):
     if buildNamespace(build) is not None:
         raise "Build can only have one namespace"

  def removeBuildNamespace(build, ns):
      assertPerm('admin')
      if buildNamespace(build) != ns:
          raise "Build is not in that namespace"

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

How does uniqueness of filenames work given namespaces? Does the namespace get added into the path to the rpms, or some unique id (hash? build id?)? If it's the namespace, I guess changeNamespace moves files around too?

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

Main question is how the heck do you figure out which namespace a build is coming from and then reference it back when you're using the command line?

For non-null namespace tags, you could deduce it from the tag, so you'd see:

Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
foo-1.2-3.el6                             rhel-6                alice
bar-3.14-159                              myproject             bob

and say 'okay, that's foo-1.2-3.el6 from the rhel namespace, and bar-3.14-159 from the mycompany namespace', and then run

$ koji buildinfo mycompany::bar-3.14-159

You'd have an extra step working out the namespace from the tag though, unless you could run something like:

$ koji buildinfo --ns-for-tag myproject bar-3.14-159

If you had a scratch build tag with null namespace, you could have worse problems though:

Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
foo-1.2-3.el6                             scratch               alice
foo-1.2-3.el6                             scratch               alice
foo-1.2-3.el6                             scratch               bob
foo-1.2-3.el6                             scratch               carol
foo-1.2-3.el6                             scratch               bob
foo-1.2-3.el6                             scratch               alice

If Carol's happy with her build, how does she look that up from the command line without hitting one of the other builds?

I was thinking a 'Namespace' column would solve the problem nicely; but it doesn't really solve it for null-namespace builds, and would run into problems fitting in 80 characters.

A few ideas:

 - for null-namespace builds, maybe 12345::foo-1.2-3.el6 where 12345 is the buildid would work? are namespaces allowed to begin with numbers?

 - maybe always displaying builds as ns:nvr whenever the namespace isn't the default ns would be reasonable?

 - if so, maybe letting the client choose what 'their' default namespace is would make it a bit more palettable

 - if so, maybe some way of saying "my default namespace is actually rhel + projectA" and having koji enforce that no projectA build/rpm clashes with a rhel build/rpm would be useful; likewise for rhel and projectB perhaps, while projectA and projectB builds could still clash.

Cheers,
aj

-- 
Anthony Towns <atowns at redhat.com>
Red Hat Release Engineering