I guess we'll need input from @puiterwijk on this one

This might be caused by the out of space on pkgs01.stg, but it still seems to be happening after I fixed that.

It might be that repospanner needs to catch up on it's syncing before this repo is back to normal...

This is the cause of a disrepancy in symref updates between various repoSpanner builds.
I'm now adding symref updating to it, so that we can make sure all repos have the correct symrefs.

Note that a temporary workaround would be to just do a "git checkout master" (or any other ref) after the cloning.
The actual issue is just that Git isn't told what the standard ref is.

Status report: This is waiting some changes in the repoSpanner code and then working out a coordination time with CentOS to roll out the changes on both sides.

Time to check back: 2019-03-01

This is fixed in repoSpanner, waiting on our pagure 5.3 upgrade then we will update this. Hopefully in the next few weeks.

So, this now behaves a bit differently:

Cloning into 'atinject'...
remote: Welcome to repoSpanner 0.4+1.f38383546f7ce0e88ec7b9c5bf7959521af2c941.el7.infra, node fedora01.rpms.stg.fedoraproject.org
remote: Building packfile
remote: Packfile built, sending
remote: Packfile sent
Receiving objects: 100% (121/121), 70.93 KiB | 115.00 KiB/s, done.
warning: remote HEAD refers to nonexistent ref, unable to checkout.

But then checking out any branch after that works fine.

@kevin With the new repoSpanner, we can fix this, from the server-side.
If we're sure that the entire cluster is 0.4 or higher, edit the symref of the repo.

It seems like all forks are behaving this way now. Can we mass fix the existing ones and fix it so new ones don't have the issue?

@bowlofeggs Any ideas on this one? as patrick mentioned there is a server side command to fix these, but I am not sure what it is... should we use that or try and fix this in repospanner?

Hi @kevin,

I wonder if this comment from @puiterwijk is along the lines of what we need:

https://github.com/repoSpanner/repoSpanner/issues/92#issuecomment-537061852

Yeah, I think so...

sadly, a simple try doesn't work:

[root@pkgs01 ~][STG]# repospanner admin repo edit rpms/atinject HEAD=refs/heads/master
panic: No admin URL configured

goroutine 1 [running]:
repospanner.org/repospanner/server/cmd.getAdminClient(0xba26e0)
/builddir/build/BUILD/repoSpanner-0.5/server/cmd/admin.go:127 +0x609
repospanner.org/repospanner/server/cmd.runAdminEditRepo(0x141ad20, 0xc00000c4c0, 0x2, 0x2)
/builddir/build/BUILD/repoSpanner-0.5/server/cmd/admin-repo-edit.go:116 +0x34c
github.com/spf13/cobra.(Command).execute(0x141ad20, 0xc00000c480, 0x2, 0x2, 0x141ad20, 0xc00000c480)
/builddir/build/BUILD/repoSpanner-0.5/vendor/github.com/spf13/cobra/command.go:766 +0x2cc
github.com/spf13/cobra.(Command).ExecuteC(0x141c020, 0xc0001e4e00, 0xc8e6d1, 0x20)
/builddir/build/BUILD/repoSpanner-0.5/vendor/github.com/spf13/cobra/command.go:852 +0x2fd
github.com/spf13/cobra.(*Command).Execute(0x141c020, 0xc0001f4c00, 0xc78e15)
/builddir/build/BUILD/repoSpanner-0.5/vendor/github.com/spf13/cobra/command.go:800 +0x2b
repospanner.org/repospanner/server/cmd.Execute()
/builddir/build/BUILD/repoSpanner-0.5/server/cmd/root.go:22 +0x2d
main.main()
/builddir/build/BUILD/repoSpanner-0.5/cmd/repospanner/main.go:17 +0x3b

@kevin,

Looking through the code, that error message seems to indicate that the pkgs01.stg host doesn't have an admin['url'] setting defined in its config file. Here's an example of that setting:

https://github.com/repoSpanner/repoSpanner/blob/06ae75f75be7cb7b540e4e60bb0ceb807f35cc83/config.yml.example#L4-L5

Indeed, I do not see one in roles/repospanner/server/templates/repoSpanner.yml

What should we add there? something like the default using a localhost?

@kevin to be honest, I'm not completely sure what that setting does, but I am guessing it is used to decide which URL to use for the client to talk to an admin API. So I think you could probably put the host name of any node there, but again, not 100% sure.

This is fixed. We no longer are using repoSpanner here.