-
Notifications
You must be signed in to change notification settings - Fork 472
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automated protobuf generation #30
Conversation
Hi @howardjohn. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
1301c93
to
8204111
Compare
8204111
to
4c8ab34
Compare
@bowei do you have a chance to take a look? This is blocking Istio adoption - right now we are using a fork with these changes |
@howardjohn We discussed this on Service APIs call and want to move forward, this would be great with verification and generation scripts mirroring what exists in k/k. |
4c8ab34
to
de40610
Compare
Sorry for the delay here. I have updated the PR to rebase and add a verification script. Looks like we need a new prow job as well, I can send a PR for that |
/assign @robscott |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your work on this! This looks really close but had a few nits/questions. One question that didn't really fit with any single line of code is simply what would happen if a field was added or removed from a struct - would the int associated with the protobuf tag for fields below that field in a struct change? If so, would that break things?
kubebuilder.mk
Outdated
@@ -17,6 +17,10 @@ IMG ?= controller:latest | |||
# Produce CRDs that work back to Kubernetes 1.11 (no version conversion) | |||
CRD_OPTIONS ?= "crd:trivialVersions=true" | |||
|
|||
DOCKER ?= docker | |||
# Image to build protobugs | |||
PROTO_IMG ?= k8s.gcr.io/kube-cross:v1.13.5-1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like there's a slightly newer version of this image now, any reason not to use it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It didn't exist at the time, I'll update it
hack/verify-kubebuilder.sh
Outdated
@@ -0,0 +1,31 @@ | |||
#!/bin/bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is this called verify-kubebuilder.sh
? Isn't this more about just verifying proto generation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I figured we could extend this to verify everything in kubebuilder, but I can make this proto specific
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 that makes sense. I think I'd prefer a proto specific name for the file to better match the other verify-* script names. I may be misunderstanding this, but isn't proto generation unrelated to kubebuilder, and instead something we're adding on top with go-to-protobuf?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a good point.. the kubebuild.mk also has format, vet, etc which aren't quite kubebuilder either which is why I placed this here. For now ill change the verify script
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that's also a good point, confusing naming.
I just tested this, removing a field and regen, no numbers change. If we then add another field, that one is given a new number, it does not re-use the old one. So I think this is working as expected in that regard |
/retest |
Thanks! /lgtm |
Thanks @bowei I have updated with your suggestions |
0ec66c2
to
92859a8
Compare
@bowei this is ready for review |
/ok-to-test |
I set up the prow job in kubernetes/test-infra#16379 which can be enabled after this is merged |
@bowei do you have a chance to take a look at this today? |
/lgtm |
18807e3
to
db5f0b9
Compare
I have updated this to resolve some merge conflicts |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: bowei, howardjohn The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
We will probably want kubernetes/test-infra#16379 or we may end up with some out of sync issues |
type CertificateObjectReference = LocalObjectReference | ||
|
||
// ListenerExtensionObjectReference identifies a listener extension object | ||
// within a known namespace. | ||
// | ||
// +k8s:deepcopy-gen=false | ||
// +protobuf=false | ||
type ListenerExtensionObjectReference = LocalObjectReference | ||
|
||
// RouteObjectReference identifies a route object within a known namespace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this have +protobuf=false
too? I'm trying to rebase #111 and getting failures:
api/v1alpha1/generated.pb.go:1684:33: m.Routes[iNdEx].MarshalToSizedBuffer undefined (type RouteObjectReference has no field or method MarshalToSizedBuffer)
api/v1alpha1/generated.pb.go:3155:9: e.Size undefined (type RouteObjectReference has no field or method Size)
api/v1alpha1/generated.pb.go:3758:63: f.String undefined (type RouteObjectReference has no field or method String)
api/v1alpha1/generated.pb.go:5705:21: cannot use LocalObjectReference literal (type LocalObjectReference) as type RouteObjectReference in append
api/v1alpha1/generated.pb.go:5706:39: m.Routes[len(m.Routes) - 1].Unmarshal undefined (type RouteObjectReference has no field or method Unmarshal)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding is that Go associates methods with the concrete types, not the alias. So we cannot have ListenerExtensionObjectReference.DeepCopy
and RouteObjectReference.DeepCopy
, since then there are two DeepCopy associated with LocalObjectReference
. The go-to-protobuf generator doesn't seem to handle this well. RouteObjectReference
is somehow deemed as the chosen alias that represents LocalObjectReference
(possibly its the last one processed?), so if we mark it protobuf=false
there will be no type for LocalObjectReference
generated.
Since you are making RouteObjectReference
no longer a type, it should have protobuf generated, but now there is probably nothing generating LocalObjectReference
? So maybe we need to remove protobuf=false from one of these type aliases now?
Let me know if that makes sense, I can try to get things working on your PR if not
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense. Thanks!
Fixes #11