Skip to content
This repository has been archived by the owner on Oct 17, 2022. It is now read-only.

Migrate to go mod #120

Merged
merged 3 commits into from
Mar 29, 2021
Merged

Migrate to go mod #120

merged 3 commits into from
Mar 29, 2021

Conversation

ganeshmaharaj
Copy link
Contributor

No description provided.

Signed-off-by: Ganesh Maharaj Mahalingam <gmmaharaj@gmail.com>
@coveralls
Copy link

coveralls commented Mar 26, 2021

Coverage Status

Coverage decreased (-0.02%) to 68.891% when pulling 701f218 on ganeshmaharaj:go-mod into e5228d3 on intel:master.

@markdryan
Copy link
Contributor

I had a play around with this this morning and I still can't get it to work, I mean ccloudvm create still fails with go1.16. I think this commit is probably fine but we need something else as well to get things working. At this stage I think we need to stop using the GOPATH to locate the workloads. Perhaps we can copy them to a location that the systemd service can find when one does a ccloudvm create. We already look in ~/.ccloudvm/workloads so we could just copy them in there. I need a bit more time to fix this.

@markdryan
Copy link
Contributor

Perhaps we can copy them to a location that the systemd service can find when one does a ccloudvm create.

Of course the problem is, how can we copy them if we can't find them? Perhaps we could just embed them into the binary. This would add an extra step when adding a workload.

@markdryan
Copy link
Contributor

markdryan commented Mar 26, 2021

@ganeshmaharaj In the meantime you can get things to work by copying the workload you want into ~/.ccloudvm/workloads. If you do this the code that uses the GOPATH which no longer works, won't get called.

@ganeshmaharaj
Copy link
Contributor Author

@markdryan with this patch and setting GO111MODULE to be auto go env -w GO111MODULE=auto I was able to build and run a VM and find the right files. A simple program as below shows the issue.

package main

import (
	"fmt"
	"go/build"
)

func main() {
	bld := build.Default
	p, err := bld.Import("github.com/intel/ccloudvm", "", build.FindOnly)
	fmt.Printf("%+v :: %+v\n", p, err)
}

The output of the test is

gmmaha@altair <> test % go run main.go 
&{Dir:/home/gmmaha/go/src/github.com/intel/ccloudvm Name: ImportComment: Doc: ImportPath:github.com/intel/ccloudvm Root:/home/gmmaha/go SrcRoot:/home/gmmaha/go/src PkgRoot:/home/gmmaha/go/pkg PkgTargetRoot:/home/gmmaha/go/pkg/linux_amd64 BinDir:/home/gmmaha/go/bin Goroot:false PkgObj:/home/gmmaha/go/pkg/linux_amd64/github.com/intel/ccloudvm.a AllTags:[] ConflictDir: BinaryOnly:false GoFiles:[] CgoFiles:[] IgnoredGoFiles:[] InvalidGoFiles:[] IgnoredOtherFiles:[] CFiles:[] CXXFiles:[] MFiles:[] HFiles:[] FFiles:[] SFiles:[] SwigFiles:[] SwigCXXFiles:[] SysoFiles:[] CgoCFLAGS:[] CgoCPPFLAGS:[] CgoCXXFLAGS:[] CgoFFLAGS:[] CgoLDFLAGS:[] CgoPkgConfig:[] TestGoFiles:[] XTestGoFiles:[] Imports:[] ImportPos:map[] TestImports:[] TestImportPos:map[] XTestImports:[] XTestImportPos:map[] EmbedPatterns:[] EmbedPatternPos:map[] TestEmbedPatterns:[] TestEmbedPatternPos:map[] XTestEmbedPatterns:[] XTestEmbedPatternPos:map[]} :: <nil>
gmmaha@altair <> test % GO111MODULE=on go run main.go 
&{Dir: Name: ImportComment: Doc: ImportPath:github.com/intel/ccloudvm Root: SrcRoot: PkgRoot: PkgTargetRoot: BinDir: Goroot:false PkgObj: AllTags:[] ConflictDir: BinaryOnly:false GoFiles:[] CgoFiles:[] IgnoredGoFiles:[] InvalidGoFiles:[] IgnoredOtherFiles:[] CFiles:[] CXXFiles:[] MFiles:[] HFiles:[] FFiles:[] SFiles:[] SwigFiles:[] SwigCXXFiles:[] SysoFiles:[] CgoCFLAGS:[] CgoCPPFLAGS:[] CgoCXXFLAGS:[] CgoFFLAGS:[] CgoLDFLAGS:[] CgoPkgConfig:[] TestGoFiles:[] XTestGoFiles:[] Imports:[] ImportPos:map[] TestImports:[] TestImportPos:map[] XTestImports:[] XTestImportPos:map[] EmbedPatterns:[] EmbedPatternPos:map[] TestEmbedPatterns:[] TestEmbedPatternPos:map[] XTestEmbedPatterns:[] XTestEmbedPatternPos:map[]} :: no required module provides package github.com/intel/ccloudvm: go.mod file not found in current directory or any parent directory; see 'go help modules'

I am still not sure why go will not fall back to the default src path for searching. I also tried switching over to golang.org/x/tools/packages to see if that would work. I will keep you posted on what I find.

@markdryan
Copy link
Contributor

I am still not sure why go will not fall back to the default src path for searching. I also tried switching over to golang.org/x/tools/packages to see if that would work. I will keep you posted on what I find.

I think that code is just inherently fragile and we should just remove it.

I can merge this MR now as I have confirm that it does build.

@markdryan
Copy link
Contributor

Although maybe I'll wait until I have a full fix. I can push the updates to this PR I think. The README will need to be updated as well.

@@ -41,6 +42,10 @@ import (

const ccloudvmPkg = "github.com/intel/ccloudvm"

//go:embed "workloads/*"
var wkldfs embed.FS
var allwklds, _ = fs.ReadDir(wkldfs, "workloads")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great. So no need to ever update this.

The previous method of searching for workload files in the source-tree
is broken with new go versions as GOPATH is getting deprecated.
Migrating to embed to hold all workload yamls in the binary and feed
from there.

Signed-off-by: Ganesh Maharaj Mahalingam <ganesh.mahalingam@intel.com>
Signed-off-by: Ganesh Maharaj Mahalingam <gmmaharaj@gmail.com>
@markdryan markdryan merged commit e0a3c62 into intel:master Mar 29, 2021
@ganeshmaharaj ganeshmaharaj deleted the go-mod branch March 29, 2021 14:57
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants