EDGECONTAINERPB: APIV1 Request Fields Dont Match SmokeTest/Documentation - FAIL

[lmcdasm]

Client

edgecontainerPB

Environment

Alpine Docker on GKE VM

Go Environment

$ go version
go version go1.20.5 linux/amd64

$ go env

GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/daniel_c_smith/.cache/go-build"
GOENV="/home/daniel_c_smith/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/daniel_c_smith/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/daniel_c_smith/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.20.5"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/daniel_c_smith/code/cluster_watch/go.mod"
GOWORK=""
CGO_CFLAGS="-O2 -g"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-O2 -g"
CGO_FFLAGS="-O2 -g"
CGO_LDFLAGS="-O2 -g"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1639841726=/tmp/go-build -gno-record-gcc-switches"

here you can see that ListClusters needs to be passed a ListClusters Request

When you look at the struct for ListClusterRequests - you see that it has the following Fields and says that "Parent" should be the Location that holds the Collection

However, when you try to pass "Parent: "us-central1" as its written - this fails

with this error that seems to indicate its looking for a Project ID:

When you then try to pass a actual Project ID in the passing this fails with an Error as well:

When you then try to figure out the Prefix, we end up playing "trial and error" with a bunch of malformed syntax.

What makes this EVEN more crazy is that if you look at the SMOKE_TEST For the package, the Fields dont match the API

And when i try to do this, I get errors that the Field (Project ID) doesnt exist .

Expected behavior

I expect that the API fields are as documented and that the example that is AutoGen works. I would expect the Smoke Test Code to work as an example, but neither do.

Actual behavior

API doesnt work as written

Screenshots

See above

Additional context

[lmcdasm]

Hello>

Adding a bit more reference.

When i go look at the gitrepo for the apiv1 ListClustersRequest Type,
This is what is in GIT REPO for the struct:

LINK: https://github.com/googleapis/google-cloud-go/blob/main/container/apiv1/containerpb/cluster_service.pb.go

And this is what is in pkg.go.dev.:

LINK: https://pkg.go.dev/cloud.google.com/go/edgecontainer/apiv1/edgecontainerpb#ListClustersRequest

[lmcdasm]

WORKAROUND/CORRECT MAPPING.

When you look inside the current APIV1 code base, you can find this nice bit of information, where we can then "know" that the ListCluster_smoketest.go can work, since its calling Depracted Fields - as well, the information about what Parent should look like (the format of "/project//locations/" (and or - for all locations) is NOT present in the go.pkg.dev release.

Perhaps its implied for "all things " to use the "project//locations/" pattern, but would be sure useful to have the docs have a bit more than "Lists clusters in locations" as other libraries have

Cheers,
dasm

[codyoss]

Hey,

It looks like you found the correct mapping Parent: "projects/PROJECT_ID/locations/LOCATION",. I agree that from the api docs this is not super clear today. These clients are generated from a public spec so I think the project documentation needs to be updated and that will filter down to the client. Please provide this feedback via the services support page: https://cloud.google.com/distributed-cloud/edge/latest/docs/getting-support

[codyoss]

I also filed an issue for our backlog to see if we can provide better hints when the attribute documentation does not mention the required formats.

[lmcdasm]

Hey @codyoss

Thanks alot! in the end i did find the pattern and such - seems like just a bit of a doc glitch and some comments missed in the translation to apiv1 (i didnt go "too far" back, but its in there and as you said the AutoGen could use some love ).

No Harm No Foul - mostly documentation fix up .

Thanks again for the follow up !
Daniel