[Gluster-devel] Building GD2 from glusterd2-v5.0-0-vendor.tar.xz fails on CentOS-7

[Niels de Vos]

On Tue, Oct 30, 2018 at 12:45:35PM +0530, Kaushal M wrote:
> On Tue, Oct 30, 2018 at 11:50 AM Kaushal M <kshlmster at gmail.com> wrote:
> >
> > On Tue, Oct 30, 2018 at 2:20 AM Niels de Vos <ndevos at redhat.com> wrote:
> > >
> > > Hi,
> > >
> > > not sure what is going wrong when building GD2 for the CentOS Storage
> > > SIG, but it seems to fail with some golang import issues:
> > >
> > >   https://cbs.centos.org/kojifiles/work/tasks/5141/595141/build.log
> > >
> > >   + cd glusterd2-v5.0-0
> > >   ++ pwd
> > >   + export GOPATH=/builddir/build/BUILD/glusterd2-v5.0-0:/usr/share/gocode
> > >   + GOPATH=/builddir/build/BUILD/glusterd2-v5.0-0:/usr/share/gocode
> > >   + mkdir -p src/github.com/gluster
> > >   + ln -s ../../../ src/github.com/gluster/glusterd2
> > >   + pushd src/github.com/gluster/glusterd2
> > >   ~/build/BUILD/glusterd2-v5.0-0/src/github.com/gluster/glusterd2 ~/build/BUILD/glusterd2-v5.0-0
> > >   + /usr/bin/make PREFIX=/usr EXEC_PREFIX=/usr BINDIR=/usr/bin SBINDIR=/usr/sbin DATADIR=/usr/share LOCALSTATEDIR=/var/lib LOGDIR=/var/log SYSCONFDIR=/etc FASTBUILD=off glusterd2
> > >   Plugins Enabled
> > >   Building glusterd2 v5.0-0
> > >   # github.com/gluster/glusterd2/vendor/github.com/coreos/etcd/clientv3
> > >   vendor/github.com/coreos/etcd/clientv3/client.go:346: cannot use c.tokenCred (type *authTokenCredential) as type credentials.PerRPCCredentials in argument to grpc.WithPerRPCCredentials:
> > >         *authTokenCredential does not implement credentials.PerRPCCredentials (wrong type for GetRequestMetadata method)
> > >                 have GetRequestMetadata("context".Context, ...string) (map[string]string, error)
> > >                 want GetRequestMetadata("github.com/gluster/glusterd2/vendor/golang.org/x/net/context".Context, ...string) (map[string]string, error)
> > >   vendor/github.com/coreos/etcd/clientv3/client.go:421: cannot use client.balancer (type *healthBalancer) as type grpc.Balancer in argument to grpc.WithBalancer:
> > >         *healthBalancer does not implement grpc.Balancer (wrong type for Get method)
> > >                 have Get("context".Context, grpc.BalancerGetOptions) (grpc.Address, func(), error)
> > >                 want Get("github.com/gluster/glusterd2/vendor/golang.org/x/net/context".Context, grpc.BalancerGetOptions) (grpc.Address, func(), error)
> > >   vendor/github.com/coreos/etcd/clientv3/retry.go:145: cannot use retryKVClient literal (type *retryKVClient) as type etcdserverpb.KVClient in return argument:
> > >         *retryKVClient does not implement etcdserverpb.KVClient (wrong type for Compact method)
> > >                 have Compact("context".Context, *etcdserverpb.CompactionRequest, ...grpc.CallOption) (*etcdserverpb.CompactionResponse, error)
> > >                 want Compact("github.com/gluster/glusterd2/vendor/golang.org/x/net/context".Context, *etcdserverpb.CompactionRequest, ...grpc.CallOption) (*etcdserverpb.CompactionResponse, error)
> > >   ...
> > >
> > > Did anyone else try to build this on CentOS-7 (without EPEL)?
> >
> > This occurs when Go<1.9 is used to build GD2. The updated etcd version
> > we vendor (etcd 3.3) requires Go>=1.9 to compile.
> > But the failure here is strange, because CentOS-7 has golang-1.9.4 in
> > its default repositories.
> > Don't know what's going wrong here.
> 
> Looked at the logs again. This is an aarch64 build. It seems that
> CentOS-7 for aarch64 is still on go1.8.
> So, we could disable aarch64 for GD2 until the newer Go compiler is available.

Thanks! But even on x86_64 there only seems to be
golang-1.8.3-1.2.1.el7.x86_64 in the buildroot. I can not find
golang-1.9.4, can you check where it comes from? The build details are
in https://cbs.centos.org/koji/taskinfo?taskID=595140 and you can check
the root.log for the packages+versions that get installed.

golang-1.10.2-1.el7 is available for x86_64, but that requires some ugly
build workaround (also easy to forget reverting when there is a golang
update). And then there is still the need for aarch64 and ppc64le.
Obviously the goal it to provide an equal set of packages on all
architectures, like we have been doing for a while now.

I'll see what replies I get from the CentOS folks, maybe there is a way
to get a golang update outside of the base repository.

Niels