I'm trying to connect to my local Kubernetes cluster hosted on minikube, here's the code for the same, now when I do go run minikube.go, it gives me an error saying:
../../../pkg/mod/k8s.io/client-go#v11.0.0+incompatible/kubernetes/scheme/register.go:26:2: module k8s.io/api#latest found (v0.19.0), but does not contain package k8s.io/api/auditregistration/v1alpha1`.
Now, I tried to manually install the package using go get then I found out that this package does not exist.
How can I make it work and fix this?.
My go.mod file in case anyone wants to see that.
Always specify matching versions of all three k8s.io/... components in your go.mod file
require (
...
k8s.io/api v0.19.0
k8s.io/apimachinery v0.19.0
k8s.io/client-go v0.19.0
...
)
Related
I have looked all over for an answer for "go.mod has malformed module path" but I have not found an answer to why I can't get a library I am writing to import. To simplify I have made a tiny library repo: https://github.com/buphmin/test-go-pkg
Note: I am using the stripe api library for structure inspiration. https://github.com/stripe/stripe-go
Problem:
I create a library, go mod init , push code and tag to github. Then try to import package to use the library elsewhere and I get an error message: 'go get: github.com/buphmin/test-go-pkg#v1.0.0: invalid version: go.mod has malformed module path "github.com/buphmin/test-go-pkg/v1" at revision v1.0.0'
I have no idea why this is an issue and I have not found an answer thus far.
Steps to Reproduce
Assuming you have go installed.
Create local folder
go mod init <your_mod>
go get github.com/buphmin/test-go-pkg/v1
error occurs
Other info
go v1.16
ubuntu 18 LTS
go mod file
Copied from the source of truth listed above: https://github.com/buphmin/test-go-pkg
module github.com/buphmin/test-go-pkg/v1
go 1.16
Edit - Answer:
My understand now with the help of #Steven Penny is that v1, v2, etc has more significance than just organization. This article explains how go treats that versioning https://www.honeybadger.io/blog/golang-go-package-management.
This:
module github.com/buphmin/test-go-pkg/v1
is not valid. Should be this:
module github.com/buphmin/test-go-pkg
Using the buffalo framework,
after bootstraping it via buffalo new <project_name>
I am trying to run buffalo dev
Expecting to see:
project running on port 3000
But I am getting those error messages instead
actions/app.go:4:2: missing go.sum entry for module providing package github.com/gobuffalo/buffalo (imported by sc_api/actions); to add:go get sc_api/actions
actions/app.go:13:2: missing go.sum entry for module providing package github.com/gobuffalo/mw-csrf (imported by sc_api/actions); to add: go get sc_api/actions
actions/app.go has been generated by buffalo, but in case you are wondering the error does match the import statement in this file.
// app.go
package actions
import (
"github.com/gobuffalo/buffalo" // 1rst line
"github.com/gobuffalo/envy"
forcessl "github.com/gobuffalo/mw-forcessl"
paramlogger "github.com/gobuffalo/mw-paramlogger"
"github.com/unrolled/secure"
"sc_api/models"
"github.com/gobuffalo/buffalo-pop/v2/pop/popmw"
csrf "github.com/gobuffalo/mw-csrf" // 2nd line
i18n "github.com/gobuffalo/mw-i18n"
"github.com/gobuffalo/packr/v2"
)
What does it mean ? How do I fix it ?
It seems the issue has nothing to do with Buffalo and more with my lack of understanding of Go in general.
running go mod tidy solved the issue
This command goes through the go.mod file to resolve dependencies:
delete the packages that are not needed
download those needed
update the go.sum
I am still unsure which of those actions did the trick... but the project runs now.
ps: I'll let the in-depth explanation/correction to the Go wizard out here.
i got the same issue when building a docker image. i tried go mod tidy and
also go get -t . as suggested here https://github.com/golang/go/issues/44129. both didnt worked for me though but updating my docker builder to version 1.18 worked.
I use go mod tidy -e solved the problem. The -e flag (added in Go 1.16) causes go mod tidy to attempt to proceed despite errors encountered while loading packages.The more about mod tidy: https://go.dev/ref/mod#go-mod-tidy
My golang service uses k8s go api to communicate with Kubernetes clusters. Some of them are v1.9.6, while some clusters of v1.17.0 were recently added.
I am using go.mod to manage dependencies. However I am having trouble combining dependencies of different versions.
For example using dependencies for the old API look like this:
module k8sOld
go 1.13
replace k8s.io/api => k8s.io/api v0.0.0-20180127130940-acf347b865f2
require (
k8s.io/api v0.0.0-20180127130940-acf347b865f2
k8s.io/apimachinery v0.0.0-20180126010752-19e3f5aa3adc
k8s.io/client-go v6.0.1-0.20180321184741-e56f95336983+incompatible
k8s.io/kube-openapi v0.0.0-20200615155156-dffdd1682719
)
When I added newer version of Kubernetes API I tried it like this:
module k8sOld
go 1.13
replace k8s.io/api => k8s.io/api v0.0.0-20180127130940-acf347b865f2
replace k8s.io/api/new => k8s.io/api v0.17.0
require (
k8s.io/api v0.0.0-20180127130940-acf347b865f2
k8s.io/apimachinery v0.0.0-20180126010752-19e3f5aa3adc
k8s.io/client-go v6.0.1-0.20180321184741-e56f95336983+incompatible
k8s.io/kube-openapi v0.0.0-20200615155156-dffdd1682719
k8s.io/api v0.17.0
k8s.io/apimachinery v0.17.0
k8s.io/client-go v0.17.0
)
I named the package for new packages "k8s.io/{subpackage}/new" and used replace to point to the newer version.
I am not sure if this is ok and that is the first question.
The second and most basic one is ,supposing I find a way to refer to newer version, how can I refer subpackages of packages?
For example how can I use k8s.io/api/core/v1?
I tried naming it like this:
"k8s.io/api/{VERSION NAMING CONVENTION}/core/v1"
But it does not seem to work.
I also tried adding k8s.io/api/core/v1 {version number} to the require part of go.mod, but it cannot be used this way.
Any ideas on how I can use different versions of k8s go api under the same hood?
My module is gitlab.com/getsote/utilities/slogger
My repository is gitlab.com/getsote/utilities/slogger.git
When I run go get gitlab.com/getsote/utilities/slogger, I get the message below.
Scotts-Mac-mini:seeding syacko$ go get gitlab.com/getsote/utilities/slogger
go get gitlab.com/getsote/utilities/slogger: module gitlab.com/getsote/utilities/slogger: git ls-remote -q origin in /Users/syacko/workspace/sotesoft/golang/pkg/mod/cache/vcs/80b3644beae1b986f1c659355360479e2463820660aa328d2edb1e571aba259b: exit status 128:
remote: The project you were looking for could not be found.
fatal: repository 'https://gitlab.com/getsote/utilities.git/' not found
Scotts-Mac-mini:seeding syacko$
The gitlab.com/getsote/utilities.git is a sub-directory and not a repository. I don't understand why go get is going to the utilities as a repository?
==========================
PREVIOUS Updates
Directory Structure:
GOPATH/src/slogger
|----go.mod
|----slogger.go
|----slogger_test.go
go.mod file
module slogger or gitlab.com/getsote/utilities/slogger -> still gets the error below
go 1.14
gitlab.com/getsote/utilities contains repository slogger.git
I have run a test to see if the issue is the number of nodes in the path. So, I create a new repository with no sub-directory and pushed the slogger code. Then ran go get gitlab.com/getsote/slogger which generate a different error message.
GOPATH/gitlab.com/getsote/test-go-mod -> create new directory and added slogger files listed above
gitblab.com/getsote/test-go-mod -> new repository with one less level
Scotts-Mac-mini:test-go-mod syacko$ go get gitlab.com/getsote/test-go-mod
go: downloading gitlab.com/getsote/test-go-mod v0.0.0-20200409023538-794310bf7cf9
go get gitlab.com/getsote/test-go-mod: gitlab.com/getsote/test-go-mod#v0.0.0-20200409023538-794310bf7cf9: verifying module: gitlab.com/getsote/test-go-mod#v0.0.0-20200409023538-794310bf7cf9: reading https://sum.golang.org/lookup/gitlab.com/getsote/test-go-mod#v0.0.0-20200409023538-794310bf7cf9: 410 Gone
server response:
not found: gitlab.com/getsote/test-go-mod#v0.0.0-20200409023538-794310bf7cf9: invalid version: git fetch -f origin refs/heads/*:refs/heads/* refs/tags/*:refs/tags/* in /tmp/gopath/pkg/mod/cache/vcs/7753c92c9bd1419156d8120684b7f3707fd207e01a2947ba89e2acfd2ecfb4d0: exit status 128:
fatal: could not read Username for 'https://gitlab.com': terminal prompts disabled
Scotts-Mac-mini:test-go-mod syacko$
This is still getting the status error of 128 for the missing version. Additionally, it is looking in the right location for the code. If this is true, then I just need help with the version missing. Moving to a shorted directory structure is doable.
========================
Newest Update
#praveent > The solution at https://medium.com/cloud-native-the-gathering/go-modules-with-private-git-repositories-dfe795068db4 didn't work for me. So I started from scratch to see how to resolve the issue.
The reason is because for a git repository it assumes that utilities is the repo and not utilities/slogger
There is a way to override this behavior by implementing go get API. But, gitlab is yet to implement the same due to security concerns. You can read more here. Gitlab issue
Update: Add reference to gitlab issue tracking this problem.
So, here is how I got this to work using gitlab.com. I'm not saying other ways will not work, they just didn't for me and my setup. First, since I don't care if the code is available to the public, I created a new group at gitlab.com. This new group is public from the start, so no need to adjust permissions. Then I create a repository called packages and cloned the repository to my local machine with the same directory structure that is in gitlab.com, gitlab.com/soteapps/packages with ~/workspace/soteapps/packages on my machine. Both of these are out side the GOPATH. I'm not sure this matters, but it is working this way, so I'm putting it here.
Under packages, I copied the slogger directory and code.
cp -R slogger ~/workspace/soteapps/packages/.
Edited the go.mod file to match the repository structure, which is in the packages directory. There is no go.mod file in the slogger directory.
module gitlab.com/soteapps/packages
go 1.14
Edited the hello.go import to match the package.
package main
import (
"fmt"
"rsc.io/quote"
"gitlab.com/soteapps/packages/slogger"
)
func main() {
fmt.Println(quote.Hello())
slogger.Info("Test message")
}
Built the program using go build -o hello and then ran it hello with the following results:
Scotts-Mac-mini:hello syacko$ hello
Hello, world.
INFO:2020/04/10 21:11:33 Test message
Scotts-Mac-mini:hello syacko$
Worked! Thank you all that helped. This wouldn't of gotten solved without your help.
Note: This only works for public repositories.
We wrote some Go code to talk to our Kubernetes cluster and fetch the IP of a Service exposed. We do it like so:
(import "gopkg.in/kubernetes/kubernetes.v1/pkg/client/restclient")
(import kubectl "gopkg.in/kubernetes/kubernetes.v1/pkg/client/unversioned")
svc, err := c.Services(k8sNS).Get(svcName)
if err != nil {
panic(l.Errorf("Could not retrieve svc details. %s", err.Error()))
}
svcIP := svc.Status.LoadBalancer.Ingress[0].IP
go get works fine, and our script executes when we do go run ... and everybody is happy. Now, as of yesterday (from the time this question is posted) on the same script - go get fails. The error is like so:
[09.07.2016 10:56 AM]$ go get
package k8s.io/kubernetes/pkg/apis/authentication.k8s.io/install: cannot find package "k8s.io/kubernetes/pkg/apis/authentication.k8s.io/install" in any of:
/usr/local/go/src/k8s.io/kubernetes/pkg/apis/authentication.k8s.io/install (from $GOROOT)
/home/ckotha/godir/src/k8s.io/kubernetes/pkg/apis/authentication.k8s.io/install (from $GOPATH)
We have not specifically used authentication package in our code. Are we importing kubernetes libraries correctly? is there another way to do this ?
ls on $GOPATH/k8s.io/kubernetes/pkg/apis/ and found this:
:~/godir/src/k8s.io/kubernetes/pkg/apis
[09.07.2016 10:53 AM]$ ls
abac apps authentication authorization autoscaling batch certificates componentconfig extensions imagepolicy OWNERS policy rbac storage
It looks like a package you imported has changed.
You can update existing repositories:
go get -u
The -u flag instructs get to use the network to update the named
packages and their dependencies. By default, get uses the network to
check out missing packages but does not use it to look for updates to
existing packages.
You do use gopkg.io to pin the version to v1, but I think you want to be more specific, eg, v1.3.6 (EDIT: this won't work because gopkg.in doesn't permit package selectors more specific than the major version.).
Alternatively, a good way to ensure code stays the same is to compile your binary and execute that, instead of using go run.