-
Notifications
You must be signed in to change notification settings - Fork 238
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
Add direct resource cloudbuildworkerpool
#1920
Add direct resource cloudbuildworkerpool
#1920
Conversation
cloudbuildworkerpool
e063990
to
b588d2a
Compare
cd1d9f2
to
12a9cd2
Compare
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.
Looks good!
12a9cd2
to
cab5dbd
Compare
return &v | ||
} | ||
|
||
func ToDateDashTime(ts *timestamppb.Timestamp) *string { |
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 am using RFC3339 (ln392).
oh, are you suggesting to rename to ToRFC3339Time
? The reason I call it ToDateDashTime
is because the kubebuilder tag +kubebuilder:validation:Format=date-time
. If using a different format, the CRD validation will return something like invalid format, expect date-time
. But I don't have a preference.
4521f1e
to
2183a70
Compare
2183a70
to
ff9774f
Compare
70624d0
to
25f5a18
Compare
/* The creation timestamp of the workerpool.*/ | ||
// +optional | ||
// +kubebuilder:validation:Format=date-time | ||
CreateTime *string `json:"createTime,omitempty"` |
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.
Move to ObservedState?
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.
done.
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.
Done.
(LLM keeps the createTime and updateTime under status
. I know we cannot easily change that). Do you know how many beta resources have createTime and updateTime under status.observedState
? If none, I would lean towards put them under status
.
// +kubebuilder:validation:Format=date-time | ||
UpdateTime *string `json:"updateTime,omitempty"` | ||
|
||
ResourceID *string `json:"resourceID,omitempty"` |
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 like this idea, but ... does naming it resourceID imply that the format will be the same as spec.resourceID? Should we call it status.link or status.selfLink or status.ref or ??? (selfLink might have collisions and might also have implications, so probably not that, unless we want to use that format)
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 want to find a clear way to show the machine status telling if CC has successfully acquired the resource, or has created the resource according to the given spec.resourceId
or metadate name
.
I like selfLink
, it is reliable and most accurate. But I want to use the selfLink from the GCP server ( not configconnector to build one). But the cloudbuild workerpool response does not have a selfLink.
} | ||
|
||
type CloudBuildWorkerPoolObservedState struct { | ||
// +required |
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.
Marking it as required in status might be limiting - we can never change this. But if it's required in the proto schema, it can't be changed there either (although technically they can change it with a v2, and then we'd be forced to do a v2, but maybe we'd be forced to do a v2 anyway in that case, so ....)
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.
Yes, that's what I'm thinking about (if the gcp server changes the field in v2, we can then change it in v2). In this specific resource, I found some interesting usage of the required/optional that I want to discuss:
- the
workerConfig
is required by the cloudbuild server, which means if we validate this in the CRD level, we can avoid the GCP requests for immutable field changes (what I did here). - the
networkConfig
is optional, but if provided, itsnetworkConfig.peeredNetwork
field is required (and immutable). Originally I set thenetworkConfig
to optional andnetworkConfig.peeredNetwork
to be required. But it does not work very well with gcp update (because it is immutable). So It feels like forcingrequired
just adds the complexity without clear benefits. So I choose to leave that field optional and expect users to figure out the right config via the GCP errors - I also put these fields in
.status.observedState
, so if users change the GCP immutable field in.spec.XXX
and got GCP error, they know what's the right config is (instatus.observedState.XXX
). And of course, Export is another option.
req := &cloudbuildpb.DeleteWorkerPoolRequest{Name: a.fullyQualifiedName(), AllowMissing: true} | ||
op, err := a.gcpClient.DeleteWorkerPool(ctx, req) | ||
if err != nil { | ||
// likely a server bug. worker_pool can be successfully deleted. |
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.
do you mean the cloud.google.com lib
Right. I've seen this once before with an LRO with an invalid response AnyPb (no "value"). We should have a complete log in artifacts/ ... if you attach / DM me the delete portion of the log I can see if it matches what I saw before (and hopefully better remember it!)
IIRC we could work around this by switching from the REST client to the proto client (which is a one liner - NewClient vs NewRESTClient). Previously we couldn't log proto requests/responses, but this is a new resource, and we can log them now, so maybe that's an easy option.
return &v | ||
} | ||
|
||
func ToDateDashTime(ts *timestamppb.Timestamp) *string { |
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.
Ah I see where the name comes from! Maybe ToOpenAPIDateTime
would be better in that case? I think the bigger question is whether we should preserve the full timestamp as provided to us (e.g. convert the timestamp to a string) ... i.e. does it matter that we drop precision (the nanos)
Project: tokens[1], | ||
ComputeNetworkID: tokens[4]}, nil | ||
} | ||
return nil, fmt.Errorf("format of computenetwork external=%q was not known (use projects/<projectId>/global/networks/<networkid>)", ref.External) |
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.
This is great ... such an improvement over the current status quo where if you get it wrong, you get really weird errors!
computenetworkID = computenetwork.GetName() | ||
} | ||
|
||
projectID := "" |
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.
We might want a TODO: extract GetProject helper function
!
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.
Done.
(A lot of weirdness around projectID and resourceID)
Looks really good. I think we're talking about the right things at this point, i.e. the details of how a KRM <-> GCP bridge should work. I do think starting with alpha lets us iterate more rapidly on these, but we could also just commit to getting it done in a single release (or even not publish this specific CRD until we are ready, e.g. by deleting it from the crd generation step) |
adcaaa7
to
e4d2f72
Compare
Awesome stuff! /approve (Sadly there's a merge conflict...) |
2481da5
to
02e2717
Compare
02e2717
to
8e01714
Compare
8e01714
to
85a3d1a
Compare
Thanks @yuwenma /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb 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 |
afd378f
into
GoogleCloudPlatform:master
Hi @yuwenma, the prow test for this resource is constantly failing. Do you mind take a look? To reproduce:
|
for sure |
Change description
Fixes #
Tests you have done
make ready-pr
to ensure this PR is ready for review.