cli: cf services shows upgrade available incorrectly

Please fill out the issue checklist below and provide ALL the requested information.

I reviewed open and closed github issues that may be related to my problem.
I tried updating to the latest version of the CF CLI to see if it fixed my problem.
I attempted to run the command with CF_TRACE=1 to help debug the issue.
I am reporting a bug that others will be able to reproduce.

To Reproduce

update a service broker so that a service upgrade is available. run cf s verify that an upgrade is available example:

Getting services in org test_org / space test_space as admin...

name                  service        plan          bound apps   last operation     broker              upgrade available
extra-small-service   p-cloudcache   extra-small                update succeeded   cloudcache-broker   yes
test1                 p-cloudcache   dev-plan                   update succeeded   cloudcache-broker   yes

run cf upgrade-service <service_name> -c '{<some json here>}' watch the service update watch --color cf s when the service finishes updating run cf s

Expected: either an upgrade should no longer be available, or the cf cli should have never allowed the -c option to succeed without the --upgrade flag

Actual: the cf s command shows that the service that was just updated has an upgrade available.

Provide more context

platform and shell details ( e.g. Mac OS X 10.11 iTerm) Mac OS X
version of the CLI you are running cf version 6.46.0+29d6257f1.2019-07-09
version of the CC API Release you are on

Note: As of January 2019, we no longer support API versions older than CF Release v284/CF Deployment v1.7.0 (CAPI Release: 1.46.0 (APIs 2.100.0 and 3.35.0).

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 15 (14 by maintainers)

Most upvoted comments

Hmm, in that case it’d be better if Cloud Controller had that check during the execution of the update action. That is because we want to keep the CLI command to never check whether update is available or not, and just defer the decision to CloudController. At least, that was the original plan when implementing the update-one feature, architecture-wise.

waterlink on Oct 7, 2019

Here is the story for ODB side: https://www.pivotaltracker.com/story/show/169123444

waterlink on Oct 15, 2019

@pnikonowicz

We have initially made this change in CAPI, but after more thinking, and taking OSBAPI and other brokers (non-ODB) in consideration, we decided to make that decision in ODB instead, and only add all relevant information to the PATCH request from CAPI to broker, so that the broker can make a decision to accept or reject it.

Here is the tracker story: https://www.pivotaltracker.com/story/show/169087442

waterlink on Oct 15, 2019