-
Notifications
You must be signed in to change notification settings - Fork 382
Add UserProvided field to service instances #2421
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: If they are not already assigned, you can assign the PR to them by writing 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 |
428b7a0
to
ecc82f4
Compare
Before this can be merged, we'll need to have clear documentation on a few items:
|
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.
Putting a hold on this for now, just so that we can make sure we have a proper discussion about the design first.
@@ -88,7 +89,9 @@ func validateServiceInstanceSpec(spec *sc.ServiceInstanceSpec, fldPath *field.Pa | |||
allErrs := field.ErrorList{} | |||
|
|||
allErrs = append(allErrs, validateObjectReferences(spec, fldPath)...) | |||
allErrs = append(allErrs, validatePlanReference(&spec.PlanReference, fldPath)...) | |||
if !spec.UserProvided { |
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 concerned about having such an important property of instances suddenly becoming optional, mostly because we have so many assumptions in our code, and this may lead to bugs.
I didn't see any proposal or implementation suggestion before this PR came about. It would have been helpful before diving into the code. Was there a design discussion and I missed it?
One idea that I'm not sure if it was considered is to have service catalog provide a placeholder class/plan for user provided services. Just so that we don't need a bunch of special cases for when it's okay to have the plan reference empty. Also it would make the code in the cli and other areas more consistent on how to list/query and display things.
I'm a bit confused about if this replaces the user provided service broker? Does it make things possible that weren't previously possible with that broker? Are they complimentary?
To be clear, I'm not totally against this change at all. I just want to have a bit of discussion before we merge, to make sure that we understand how this will work and if it replaces anything.
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 discussed this at the last f2f. It's meant to replace the ups broker, although the ups broker is really just a toy while this is intended for actual use.
A blank class/plan is an interesting idea though. What other use cases need such a thing, because I agree it's a bit cumbersome to have to many specific cases that don't require a class/plan.
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, if you are OK with redoing this to try out using a placeholder class/plan (maybe in another branch to not lose your work) and see if you like it better?
d2e90d1
to
1b63ba3
Compare
Removing the hold as we discussed on the call on Monday. |
Putting the hold back on this, think I found a better way to do this. |
allErrs = append(allErrs, validatePlanReference(&spec.PlanReference, fldPath)...) | ||
if !spec.UserProvided { | ||
allErrs = append(allErrs, validatePlanReference(&spec.PlanReference, fldPath)...) | ||
} |
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 check to make sure that Plan is blank in the case of a UPS Instance?
var errMsg string | ||
allErrs := field.ErrorList{} | ||
if !userProvided { |
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 in the "else" case we need to make sure Plan is empty.
paramSecret := &corev1.Secret{ | ||
Data: map[string][]byte{ | ||
"credentials": []byte("{\"credentials\":\"{\\\"username\\\":\\\"foo\\\",\\\"password\\\":\\\"bar\\\"}\"}"), | ||
//"credentials": []byte("{\"username\":\"foo\",\"password\":\"bar\"}"), |
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.
is this comment needed?
// TestReconcileServiceBindingUserProvided tests reconcile binding | ||
// to ensure bindings that reference an instance with UserProvided | ||
// set and no class/plan work | ||
func TestReconcileServiceBindingUserProvided(t *testing.T) { |
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 we have a test for a UPS that has empty creds? Meaning no auth (or even endpoint URL) is required to use the service.
upsDash := "" | ||
instance.Status.InProgressProperties = inProgressProperties | ||
instance.Status.UserProvided = true | ||
//readyCond := newServiceInstanceReadyCondition(v1beta1.ConditionFalse, errorProvisionCallFailedReason, "User provided instance successfully created") |
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 we still need the comment?
@@ -558,6 +558,41 @@ func TestWithNoPlanSucceedsWithMultiplePlansFromDifferentClasses(t *testing.T) { | |||
} | |||
} | |||
|
|||
func TestWithUPSWorks(t *testing.T) { |
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.
Is this just testing to make sure that the admission controller doesn't mess with the UPS flag?
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 so, shouldn't we have 2 tests? one with userProvided set to true and one set to false - and then line 579 have tc.userProvided on the right side of the expression?
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.
To test that it doesn't mess with it in both situations
@jberkhahn: PR needs rebase. 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. |
This PR is a
What this PR does / why we need it:
This PR implements User Provided Services, where a user can provision a service instance that is not associated with an extant service plan, class, or broker. This is typically used to use some pre-existing database and manage use of it with the normal service-catalog workflow.
Docs to follow, submitting this now to get some input on the viability of this method of implementation.
Which issue(s) this PR fixes
Fixes #2189
Please leave this checklist in the PR comment so that maintainers can ensure a good PR.
Merge Checklist:
breaking the chart release and existing clients who provide a
flag that will get an error when they try to update