-
Notifications
You must be signed in to change notification settings - Fork 382
Delete field for instance and binding #2037
Changes from 8 commits
bf96b33
63f3c31
0859979
d3fae37
a5f126f
93dad71
fd8ca77
4821928
fe2f92a
283522c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -774,6 +774,12 @@ type ServiceInstanceSpec struct { | |
// allows for parameters to be updated with any out-of-band changes that have | ||
// been made to the secrets from which the parameters are sourced. | ||
UpdateRequests int64 | ||
|
||
// DeletionRequested provides a mechanism for requesting a delete without | ||
// performing a direct delete (which cannot be undone in cases where the | ||
// delete is rejected by the broker). This is the recommended way to | ||
// delete, to avoid resources becoming stuck in the deletion phase. | ||
DeletionRequested metav1.Time | ||
} | ||
|
||
// ServiceInstanceStatus represents the current status of an Instance. | ||
|
@@ -1025,6 +1031,12 @@ type ServiceBindingSpec struct { | |
// settable by the end-user. User-provided values for this field are not saved. | ||
// +optional | ||
UserInfo *UserInfo | ||
|
||
// DeletionRequested provides a mechanism for requesting a delete without | ||
// performing a direct delete (which cannot be undone in cases where the | ||
// delete is rejected by the broker). This is the recommended way to | ||
// delete, to avoid resources becoming stuck in the deletion phase. | ||
DeletionRequested metav1.Time | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I still think this should be |
||
} | ||
|
||
// ServiceBindingStatus represents the current status of a ServiceBinding. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -865,6 +865,12 @@ type ServiceInstanceSpec struct { | |
// been made to the secrets from which the parameters are sourced. | ||
// +optional | ||
UpdateRequests int64 `json:"updateRequests"` | ||
|
||
// DeletionRequested provides a mechanism for requesting a delete without | ||
// performing a direct delete (which cannot be undone in cases where the | ||
// delete is rejected by the broker). This is the recommended way to | ||
// delete, to avoid resources becoming stuck in the deletion phase. | ||
DeletionRequested metav1.Time `json:"deletionRequested,omitempty"` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this still the right name now that it's not a bool? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nope |
||
} | ||
|
||
// ServiceInstanceStatus represents the current status of an Instance. | ||
|
@@ -1127,6 +1133,12 @@ type ServiceBindingSpec struct { | |
// settable by the end-user. User-provided values for this field are not saved. | ||
// +optional | ||
UserInfo *UserInfo `json:"userInfo,omitempty"` | ||
|
||
// DeletionRequested provides a mechanism for requesting a delete without | ||
// performing a direct delete (which cannot be undone in cases where the | ||
// delete is rejected by the broker). This is the recommended way to | ||
// delete, to avoid resources becoming stuck in the deletion phase. | ||
DeletionRequested metav1.Time `json:"deletionRequested,omitempty"` | ||
} | ||
|
||
// ServiceBindingStatus represents the current status of a ServiceBinding. | ||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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 still think this should be
deprovisionTimestamp
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.
with this being a timestamp, do we expect people to actually set the time? That seems odd to me. And what does its value mean? What if its Jan 1, 1970? What is its Dec 31, 2020? Are we really supporting scheduled deletes? Is that even a thing in kube?
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.
people should not set the time, svcat would, and if we can hijack the k8s delete command, that would.
time before now means do a delete. So if Jan 1, 1970 and the resource is not deleted, try to delete it. k8s does not support a future date, see deletionTimestamp
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.
Did we agree to hijack delete? And we need it to work with vanilla kubectl, so I do not think asking people to set a time is a good UX, when 99+% of the time I bet they mean "do it now".
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 think it is bad UX to not have a time tagged to when you attempted that action. How do you know if the status changed before of after a delete was requested? How do you know when service catalog should use a bigger hammer to unbind or deprovision the thing?
the validator could hijack the setting of these field to be set to now. so user sets it to anything they want, including true or now, and then the validator replaces that with time.Now().
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'm not against there being a timestmap someplace. What I'm against is making the user set a timestamp as their UX for delete(). That's a weird design. The normal path for Kube is the user does an HTTP DELETE and as a side effect a timestamp is set. That's very different.
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 are outside the area of calling DELETE directly on any of our objects.
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.
Personally I am fine with keeping the name as it, with a single field that's just a timestamp and relying on svcat to handle calling it appropriately.
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.
If we stay with an api server, the clear choice is to make a sub-resource for each type to do the deprovision or unbind, and those methods modify this field. then the user flow is
kubectl unbind ServiceInstance foobar
but in the direction service catalog should go using CRDs that is not an option, so I am saying the existence of the field, even an empty string, allows the admission controller to set it to a correct timestamp.