@thockin - do you want to have this in 1.3? If not, let sit on that for some time.

Of course. I feel like it's a few hours from working, but it's mostly in
my off time (I was out of office yesterday :). I'll try not to let it
distract anyone else.
On May 21, 2016 3:04 AM, "Wojciech Tyczynski" notifications@github.com
wrote:

@thockin https://github.com/thockin - do you want to have this in 1.3?
If not, let sit on that for some time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25978 (comment)

A new push of this is up. The new push incorporates Daniel's registration
fix and a patch on top of that to use a --self-register flag to not do
registration in some pkgs.

Alas:

pkg/api/unversioned/zz_generated.deep_copy.go:296: undefined:
time.DeepCopy_time_Time

The new generator is not recognizing time as out of bounds for expecting
it to have generated functions. @wojtek-t, if you have a few minutes.

On Sat, May 21, 2016 at 8:28 AM, Tim Hockin notifications@github.com
wrote:

Of course. I feel like it's a few hours from working, but it's mostly in
my off time (I was out of office yesterday :). I'll try not to let it
distract anyone else.
On May 21, 2016 3:04 AM, "Wojciech Tyczynski" notifications@github.com
wrote:

@thockin https://github.com/thockin - do you want to have this in 1.3?
If not, let sit on that for some time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
<
#25978 (comment)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#25978 (comment)

This PR is a totally half-baked mess, but I think I have actually achieved deep-copy and conversion to be autogenerated. To do it, I had to bend make to my will. I don't know if this will be maintainable, but I want to see if I can clean it up and either document it well enough to keep or else extract the kernel of the logic into a Real Program.

As of right now, it actually compiles. Not sure if any symbols are missing or whatnot.

@thockin while we discuss options, is there any harm in reverting the commit to regain status quo?

I think it's the right thing to do, but the harm is that it's a huge PR and it needs constant rebases.

Throwing out a proposal, though I doubt it will stick.

What if we built with a build-tag which out-of-tree users would not use. If the tag was specified, we would link the code that triggers the need for autogenerated code to be present. For normal users (go get) you would not get that code.

@lavalamp @caesarxuchao this could provide temporary respite for people linking the client and getting crap we don't want....?

Sadly Go has no notion of "weak symbols" like good old C and C++.

The longer this sits the harder it will be to roll back. What irks me most is not rebasing it and trying again, it's that I don't actually know how to fix this once and for all. Which means it may be a long time before I get back to it, which means it will probably rot. If we don't have clarity by tomorrow AM, I will deliver or approve delivery of the coup-de-grace.

Does anyone have time to work up a rollback PR tonight? I can't do it until tomorrow.

I am opposed to rolling this back.

We can't check in generated code into the main repo. It's hostile to source control.

We likely will eventually generate proto files asynchronously into another repo that is dedicated to that purpose.

The "standard Go tools" are inadequate for our use case.

The code in pkg/api and pkg/apis is not intended for use by others.

Do we need supported client libraries? Yes. Do we have any? No.

If you'd like to help develop client libraries, please participate in the API machinery SIG.
https://github.com/kubernetes/community/tree/master/sig-api-machinery

We need help implementing support for Swagger 2.0, which could then be used to generate clients.

Is anything broken that wasn't already not supposed to work? @thockin

Alternatives:

https://github.com/technosophos/kubelite
https://github.com/golang/build/tree/master/kubernetes

Another alternative is to go get from the release-1.3 branch.

See also #11606

I don't want to roll back, but I have ideas on how we can maybe
restructure. Need to sleep on it. I think I can get 96% of this PR in,
without breaking anyone, without deleting the generated code, but in a way
that is vastly easier to re-apply when restructuring is done.

Tomorrow is busy but I will try to get some time with @lavalamp et al to
ideate.

On Jul 13, 2016 10:44 PM, "Brian Grant" notifications@github.com wrote:

See also #11606 #11606

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25978 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFVgVDTLOiuFhrN_-bRY_IVLhA94dNwRks5qVcyngaJpZM4Ijc3K
.

I wasn't aware that pkg/api was explicitly unsupported. Is pkg/client also unsupported? Some of the docs say to use them, and they worked well with go get before this PR went in. From an external developer's perspective, this change is a real bother. It feels like a breaking API change even if it technically isn't one.

That said, there's not really a good solution that doesn't involve completely restructuring the code, so maybe it's just a trade-off we need to take for now.

ref #8830

@spxtr AFAIK, we do not yet have a client that is supported for use outside our own repos, especially for anyone who extracts a subset of the kubernetes repo. pkg/api is part of the apiserver implementation. Even the versioned types aren't guaranteed to be stable so long as the json doesn't change in a non-backward-compatible way.

IMO, we won't have a supported client until it's in another repo.

Swagger is our recommended means of getting the API schema, not importing our implementation.

@bgrant0607 it appears as though neither of those alternatives support the v1beta1 resources, understandably, but their utility is limited.

I'm trying to avoid having custom builds for CI, but it can be done if currently cleaning up kubernetes development flow is more important than maintaining compatibility with the standard Go toolchain.

@smarterclayton versioning is a good option for those building executables, but it is my understanding that when writing libraries, it should be avoided if possible. But perhaps my understanding is out of date or this falls into the "not possible" category.

Thanks for all the work, explanations, and suggestions, especially @thockin .

@ddgenome Could you use the release-1.3 branch for now?

My local build is working because I have not updated the version of kubernetes under $GOPATH. For CI, which creates a new workspace for each push, I have created a Makefile that clones a specific branch of kubernetes before running "go get". This seems to be working with the release-1.3 branch. Here's the relevant snippets from the Makefile.

GO = go
GO_FLAGS = -v
GO_ARGS = ./...

all: clean vet

get: k8
    $(GO) get $(GO_FLAGS) $(GO_ARGS)

generate: get
    $(GO) generate $(GO_FLAGS) $(GO_ARGS)

build: generate
    $(GO) build $(GO_FLAGS) $(GO_ARGS)

test: build
    $(GO) test $(GO_FLAGS) $(GO_ARGS)

vet: test
    $(GO) vet $(GO_FLAGS) $(GO_ARGS)

clean:
    $(GO) clean $(GO_FLAGS) $(GO_ARGS)

.PHONY: all clean get build test vet

GO_SRC = $(GOPATH)/src
K8SIO_PATH = $(GO_SRC)/k8s.io
K8_GO_PATH = $(K8SIO_PATH)/kubernetes
K8_REPO = https://github.com/kubernetes/kubernetes
K8_BRANCH = release-1.3
k8:
    mkdir -p $(K8SIO_PATH)
    git clone --branch $(K8_BRANCH) $(K8_REPO) $(K8_GO_PATH)
.PHONY: k8

Is the plan to include the auto-generated code in the release branches?

The plan is roughly to have a whole distinct repo that holds the
fully-formed and minimal-dependency-tree-ized client libs.

Getting there is a little tricker.

On Thu, Jul 14, 2016 at 8:43 AM, David Dooling notifications@github.com
wrote:

Is the plan to include the auto-generated code in the release branches?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25978 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFVgVC8rAMeK9Kfc_nxU3p6ypOfQ3x0Zks5qVlk7gaJpZM4Ijc3K
.

I sort of mean "in the mean time". That is, is the plan that release branches have the full client code until a separate repo with the fully-formed and minimal-dependency-tree-ized client libs exists?

@thockin "... changes to the API will not be e2e tested until the re-vendoring..."

"The plan is roughly to have a whole distinct repo that holds the fully-formed and minimal-dependency-tree-ized client libs."

The same argument applies to the client lib. However, the API has fewer dependencies than the client, so re-vendoring it is much simpler.

@bgrant0607 "We can't check in generated code into the main repo. It's hostile to source control."

So are Godeps and vendoring. I agree that the Go tool kit has woefully inadequate support for meta-programming, which is why we check in auto-generated code. That's why I think we should just put the existing code into 2 repos: one to generate the code, and one that is generated. This eliminates management problems, and still plays nicely with Go.

A few of us put heads together today and came up with what we think is a
viable medium-term arrangement of repos to make this nicer. In the mean
time, Chao is working on a short-term design that should alleviate the pain
significantly.

On Thu, Jul 14, 2016 at 2:04 PM, Q-Lee notifications@github.com wrote:

@thockin https://github.com/thockin "... changes to the API will not be
e2e tested until the re-vendoring..."

"The plan is roughly to have a whole distinct repo that holds the
fully-formed and minimal-dependency-tree-ized client libs."

The same argument applies to the client lib. However, the API has fewer
dependencies than the client, so re-vendoring it is much simpler.

@bgrant0607 https://github.com/bgrant0607 "We can't check in generated
code into the main repo. It's hostile to source control."

So are Godeps and vendoring. I agree that the Go tool kit has woefully
inadequate support for meta-programming, which is why we check in
auto-generated code. That's why I think we should just put the existing
code into 2 repos: one to generate the code, and one that is generated.
This eliminates management problems, and still plays nicely with Go.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25978 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFVgVAUwZ4ySWcjZEVLXwj1gTt0AQdE1ks5qVqRCgaJpZM4Ijc3K
.

/cc @thockin

@lixiaobing10051267 reports an error when git commit #28987

I meet the similar error too. Do we need to config something after calling make rather than the various hack/* scripts?

root@vm:/home/paas/zxp/code/k8s/fork/kubernetes# git commit
Checking that it builds... OK

Checking for files that need gofmt... OK

Checking for files that need boilerplate... OK

Checking for problems with flag names... OK

Checking for API descriptions... OK

Checking for docs that need updating... make: *** No rule to make target `/*.go', needed by `_output/bin/deepcopy-gen'.  Stop.
!!! Error in hack/verify-munge-docs.sh:29
  'make -C "${KUBE_ROOT}/" WHAT=cmd/mungedocs' exited with status 2
Call stack:
  1: hack/verify-munge-docs.sh:29 main(...)
Exiting with status 1
ERROR!
Some docs are out of sync between CLI and markdown.
To regenerate docs, run:
  hack/update-munge-docs.sh

Checking for swagger type documentation that need updating... 

OK

Checking for swagger spec that need updating... OK

Aborting commit

@bgrant0607

The code in pkg/api and pkg/apis is not intended for use by others.

Do we need supported client libraries? Yes. Do we have any? No.

Kubernetes 1.3 advertises an official Go client library on this page. That client library, pkg/client, necessarily imports from pkg/api.

@peterbourgon Thanks for pointing that out. Unfortunately, that document is not correct. However, if you import from the release branch, and it works now, it should continue to work, since that branch will be fairly static.

I am offering #29017 to re-add generated files, but leave them being generated on the fly. Once we have a real go-get compatible client we can re-remove them.

Please put thoughts on that PR.

heads up-- As @foxish just noticed, if you build at head right now, you
need to make clean before checking out any branch that doesn't include
these changes, or you get a bunch of zz_*.go files in your tree and it will
not compile.

On Fri, Jul 15, 2016 at 10:35 AM, Tim Hockin notifications@github.com
wrote:

I am offering #29017 #29017
to re-add generated files, but leave them being generated on the fly. Once
we have a real go-get compatible client we can re-remove them.

Please put thoughts on that PR.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#25978 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglnwJy3GVAacMxSEejRNvsXSVa8L5ks5qV8TfgaJpZM4Ijc3K
.