currently NewClientsetFromConfig use and mutate the global scheme.Scheme. This is problematic, as if other parts of the program use it as well a data race will occur.
we need to be able to use a different scheme

In go modules, replace directives are at best viral. They tend to make adoption, upgrades, and package management harder than GOPATH. They are intended as an escape hatch for development, not a longterm resolution, and should not really ever be contained within public facing modules intended for consumption.

As such, I would like to use this issue audit the current list of requires, track upstream fixes, and if possible remove them entirely:

// pinned to solo-io's fork of cue version 308aee4ff0928a8e0ec25b9cbbdc445264038463
// note(ilackarms): this replace must be shared in any skv2-based go module due to incompatibility with upstream versions of cue
cuelang.org/go => github.com/solo-io/cue v0.4.1-0.20210623143425-308aee4ff092
github.com/docker/docker => github.com/moby/moby v0.7.3-0.20190826074503-38ab9da00309
k8s.io/apimachinery => k8s.io/apimachinery v0.19.6
k8s.io/client-go => k8s.io/client-go v0.19.6

• cuelang.org/go
• github.com/docker/docker
• k8s.io/apimachinery
• k8s.io/client-go

I saw this comments when I use the VirtualHostOptions.Extauth to build a custom_auth

	// Enterprise-only: Authentication configuration
	Extauth *v1.ExtAuthExtension `protobuf:"bytes,12,opt,name=extauth,proto3" json:"extauth,omitempty"`

Shouldn't it be open-source version configuration ? As I can see it in https://docs.solo.io/gloo-edge/master/guides/security/auth/custom_auth/

There seems to be missing go types for gloo federation such as FederatedUpstream, FederatedVirtualService, etc.
They will make it easier operating gloo fed CRDs programmatically.

Currently the gloo (edge) docs list explicit compatibility with kubernetes versions. The go.mod on the other hand, pins [recte replace] to one specific kubernetes version. For 1.10 and 1.11, this version is even outside of the gloo (edge) supported range. As well, I am unclear what I should do as a consumer if I want to use symbols from k8s.io/[email protected] in my controller, when solo-apis requires that I use a lower version. Similarly, because every kubernetes "minor" version may include breaking changes removing deprecated symbols, what should I do if I need symbols that from k8s.io/[email protected] that do not exist in solo-apis' version?

We have had a couple of prospects asking us if APIs exist for Gloo Mesh 2.0 for them to consume and build controllers/operators.

Looks like it exists for 1.2.x under the branch gloo-mesh-v1.2.17 so will be good to have something for 2.x as well.

Can you please add a license file to the repo?

Context

For projects to use the codegen package of our skv2 library, we require that they replace the cuelang dependency with our internal fork of cue.

https://github.com/solo-io/solo-apis/blob/master/go.mod#L8:

// pinned to solo-io's fork of cue version 308aee4ff0928a8e0ec25b9cbbdc445264038463
// note(ilackarms): this replace must be shared in any skv2-based go module due to incompatibility with upstream versions of cue
cuelang.org/go => github.com/solo-io/cue v0.4.1-0.20210623143425-308aee4ff092

As the comment outlines, this requires all go modules consuming skv2 to explicitly replace the dependency. For internal projects this is ok, but we should not leak our dependency management to users who only want to import the solo-apis repository as a read-only mirror for building custom controllers.

How does this affect users?

1. Create a new go project
2. go get -u github.com/solo-io/[email protected]
3. Error:

github.com/solo-io/solo-apis imports
	github.com/solo-io/solo-apis/codegen imports
	github.com/solo-io/skv2/codegen imports
	github.com/solo-io/skv2/codegen/proto imports
	cuelang.org/go/encoding/protobuf/cue: cannot find module providing package cuelang.org/go/encoding/protobuf/cue

Option 1

Depend on solo-io/cue directly

Option 2

Restructure skv2 package so that libraries which do not depend on cue or schema generation at all, do not require the dependency.

Outcome

I'm proposing we move forward with Option 1.

• 1. Update cue fork module path: https://github.com/solo-io/cue/blob/master/go.mod#L1
• 2. Update skv2 to depend on solo-io/cue directly, removing the need to replace the cue dependency: https://github.com/solo-io/skv2/blob/master/go.mod#L67
• 3. Notify the Mesh team that we have modified the skv2 library, outlining the effect is has on gloo-mesh/gloo-mesh-enterprise
• 4. Upgrade skv2 dependency in solo-apis, removing the need to replace cue as well.
• 5. Validate these changes by opening a new go project and importing only solo-apis, this should succeed.
• 6. Release these changes both as a 1.10 tag and a 1.9 tag
• 7. (NICE TO HAVE) Our skv2 dependencies in gloo/s-p are a bit out of date, can we upgrade those?

Potentially as an "in beta" decision, tags are made as gloo-v1.10.26, which means that you can check them out, but it is not possible to do a go get github.com/solo-io/[email protected]. Could we use proper semver tags as well or instead?

Currently one must go get github.com/solo-io/[email protected] and and is left with a nasty require github.com/solo-io/solo-apis v0.0.0-20220603153129-5b9fd2e8dbb7 in go.mod.

the proto is copied here, updated manually (e.g. #39). this is dangerous because our hash functions etc. depend on this in gloo

hashing bugs are VERY dangerous and this WILL bite us with customers eventually. this is a high priority bug

the library component should be light for Gloo Edge (rate limit and extauth), and avoid dependencies such as k8s which make for difficult and frequent breaking upgrades.