-
Notifications
You must be signed in to change notification settings - Fork 230
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
Fix bugzilla 1507822 - Update plan info on service instance update #2409
Fix bugzilla 1507822 - Update plan info on service instance update #2409
Conversation
return; | ||
} | ||
var updateServicePlan = function() { | ||
Catalog.getServicePlansForServiceClass($scope.serviceClass).then(function (plans) { |
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 re-requests plans for the service class on every watch update, correct? It would be better to only request them once on page load and remember them. Watches can trigger often due to status updates on the instance when it's being provisioned.
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.
Updated.
588d0ab
to
e564ac8
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.
LGTM, just one nit
var servicePlanName = _.get($scope.serviceInstance, 'spec.clusterServicePlanRef.name'); | ||
$scope.plan = _.find($scope.servicePlans, function(plan) { | ||
return _.get(plan, 'metadata.name') === servicePlanName; | ||
}); |
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.
You can use the shorthand here:
$scope.plan = _.find($scope.servicePlans, { metadata: { name: servicePlanName } });
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, updated.
var servicePlanName = _.get($scope.serviceInstance, 'spec.clusterServicePlanRef.name'); | ||
$scope.servicePlans = _.reject(plans, function(plan) { | ||
$scope.servicePlans = _.reject(plans.by('metadata.name'), function(plan) { | ||
return _.get(plan, 'status.removedFromBrokerCatalog') && (plan.metadata.name !== servicePlanName); |
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 just realized if you change the instance plan twice without leaving the page, you'll probably be able to select a removed plan again if it was initially selected. Nothing related to this PR, but we might want to test and open an issue.
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, I thought of the same thing but really really really edge case. Can't think of a good fix except to re-request the plans on a change.
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.
Check if current instance plan != $scope.plan on instance watch updates and re-filter the existing $scope.servicePlans list?
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.
True, I was actually thinking of plans that were removed after the original fetch.
e564ac8
to
dce18fd
Compare
/kind bug |
Automatic merge from submit-queue. |
Fixes bugzilla 1507822 where the service plan information is not updated automatically when the service instance is edited.