operator-sdk: `operator-sdk new` fails because it is unable to reach git.apache.org
Platform: macOS Mojave 10.14.6 - just installed via HomeBrew.
$ operator-sdk version
operator-sdk version: v0.10.0, commit: ff80b17737a6a0aade663e4827e8af3ab5a21170
Problem encountered:
I can’t run operator-sdk new because git.apache.org seems to be down. (see command output below)
I notice that thrift is also available on github, but I don’t know enough about go-lang dependency management to make use of that fact.
$ operator-sdk new test-operator --repo github.com/gzur/test-operator
INFO[0000] Creating new Go operator 'test-operator'.
INFO[0000] Created go.mod
INFO[0000] Created tools.go
INFO[0000] Created cmd/manager/main.go
INFO[0000] Created build/Dockerfile
INFO[0000] Created build/bin/entrypoint
INFO[0000] Created build/bin/user_setup
INFO[0000] Created deploy/service_account.yaml
INFO[0000] Created deploy/role.yaml
INFO[0000] Created deploy/role_binding.yaml
INFO[0000] Created deploy/operator.yaml
INFO[0000] Created pkg/apis/apis.go
INFO[0000] Created pkg/controller/controller.go
INFO[0000] Created version/version.go
INFO[0000] Created .gitignore
INFO[0000] Validating project
go: finding github.com/operator-framework/operator-sdk master
go: finding git.apache.org/thrift.git v0.0.0-20180902110319-2566ecd5d999
go: finding git.apache.org/thrift.git v0.12.0
go: git.apache.org/thrift.git@v0.12.0: unknown revision v0.12.0
go: git.apache.org/thrift.git@v0.0.0-20180902110319-2566ecd5d999: git fetch -f https://git.apache.org/thrift.git refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /Users/gissur/go/pkg/mod/cache/vcs/83dba939f95a790e497d565fc4418400145a1a514f955fa052f662d56e920c3e: exit status 128:
fatal: unable to access 'https://git.apache.org/thrift.git/': Failed to connect to git.apache.org port 443: Operation timed out
go: error loading module requirements
Error: failed to exec []string{"go", "build", "./..."}: exit status 1
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 1
- Comments: 17 (6 by maintainers)
Commits related to this issue
- storage-operator: fix Thrift source repository The Apache Git repository is (currently, and maybe indefinitely) unavailable. We replace it with the official GitHub mirror. See: https://github.com/sc... — committed to scality/metalk8s by NicolasT 5 years ago
- storage-operator: fix Thrift source repository The Apache Git repository is (currently, and maybe indefinitely) unavailable. We replace it with the official GitHub mirror. See: https://github.com/sc... — committed to scality/metalk8s by NicolasT 5 years ago
- storage-operator: fix Thrift source repository The Apache Git repository is (currently, and maybe indefinitely) unavailable. We replace it with the official GitHub mirror. See: https://github.com/sc... — committed to scality/metalk8s by NicolasT 5 years ago
@gzur Ran into the same issue. For now, I have a workaround:
Let the install get as far as it can. Then:
Then from the actual directory of the operator (for you
test-operator) run:This will fetch the remaining dependencies
Since no one seems to have explicitly mentioned it, setting:
environment variable also avoids the problem without needing to change anything. You will pick up the package from the proxy cache.
@camilamacedo86 I think you would need to delete your Go modules cache and attempt to reproduce it without that package already existing in your cache.
Having said that, I’m not sure there’s anything for us to do here since this seems to be a temporary issue with a transitive dependency. I think the workaround that @jadencodes posted (thanks!) is enough to close this issue.
Thanks for the speedy ack, and thanks for all your work making operator-development easier.
I’ll submit a PR that adds
replace git.apache.org/thrift.git => github.com/apache/thriftto go.mod scaffolds.@joelanford @camilamacedo86 I’m still seeing this in my build. Any chance to reopen? I think the following presents a pretty good case to do so:
go.modfile being edited is created during the vendor as part of the boilerplate, and I don’t believe there is a facility to add a replace in there before running the job. So while the workaround for local-development isn’t to bad, this is really playing havoc with CI jobs for people.Given the above, could we consider re-opening this and switching over to the github repos by default? It doesn’t address the fundamental issue of “could dependency download fail” but from a practical standpoint it moves the dependency hosting to much more reliable infrastructure. Especially this week as Apache is having ongoing issues.
As far as I know the ASF recommends people always download through mirrors and not directly from ASF resources. So switching to the github mirror seems like the right thing to do here.
@doltori update the
go.modand rungo mod vendorit fetches the dependencies. Commandoperator-sdk new app-operatorwill generate boiler plate and will try to fetch dependencies, so it was failing during updating dependencies. So runninggo mod vendorshould be enough