Cant delete a route with (g)cf but it works with Gem cf. about cli HOT 23 CLOSED

We have created an issue in Pivotal Tracker to manage this. You can view the current status of your issue at: http://www.pivotaltracker.com/story/show/65572058

from cli.

Hi Simon,

The version number in your cf v6 looks like an old one (I recall an old bug that omitted the actual SHA and just showed the string 'SHA'). Have you installed the v6 final release from here? https://github.com/cloudfoundry/cli/releases/tag/v6.0.0

Scott

from cli.

Out of interest, why were the linux binaries removed from the download, in favour of installers only?
It'd save people having to build from source, if the installer isn't available for their platform (or extracting the deb/rpm).

from cli.

Hiya Scott!

As stated since there is no binary and no installer for my distro of choice I had to compile myself. And Indeed, the compiled binary is from the v6.0.0 tag

➜  cli git:(v6.0.0) git log | head -n 5
commit 74c3f72a46c8c856ebf5dce39503fc97d6fd8547
Author: Max Brunsfeld and Tim Jarratt <[email protected]>
Date:   Fri Jan 31 17:40:21 2014 -0800

    Fix windows path-related test failure
➜  cli git:(v6.0.0) ./bin/build
➜  cli git:(v6.0.0) ./out/cf --version
./out/cf version 6.0.0-SHA

which is the commit https://github.com/cloudfoundry/cli/releases/tag/v6.0.0 points to.

Interestingly

➜  /tmp  wget https://github.com/cloudfoundry/cli/releases/download/v6.0.0/cf-cli_amd64.deb &> /dev/null
➜  /tmp  ar vx cf-cli_amd64.deb > /dev/null                                                             
➜  /tmp  tar -xzvf data.tar.gz  &> /dev/null
➜  /tmp  ./usr/bin/cf --version
./usr/bin/cf version 6.0.0-90db382

I shall just use the bin from the installer dpkg, since it seems to work. But strange since it supposedly should be compiled from the same commit?

from cli.

Aha, the binary on that page is not build from HEAD on the 6.0.0 tag, its build from the fourth commit from the top.

➜  cli git:(v6.0.0) ✗ git log | grep -C 20 `/tmp/usr/bin/cf --version | tr - '  ' | awk '{print $4}'`
commit 74c3f72a46c8c856ebf5dce39503fc97d6fd8547 <==== HEAD OF 6.0.0
Author: Max Brunsfeld and Tim Jarratt <[email protected]>
Date:   Fri Jan 31 17:40:21 2014 -0800

    Fix windows path-related test failure

commit 768eba51c04db74eccc69ec1a540c3ae636795ba
Author: Max Brunsfeld and Tim Jarratt <[email protected]>
Date:   Fri Jan 31 17:28:56 2014 -0800

    Refactor handling of manifest paths

commit 659fe079e65b10574b2d347b922bd52e3dbc3eab
Author: Max Brunsfeld and Tim Jarratt <[email protected]>
Date:   Fri Jan 31 17:24:20 2014 -0800

    Test UI.Failed now calls panic

    Also added testassert.AssertPanic

commit 90db382c25f5780d9dcdaa93fc2438127070979d <=== HOWDIE BUILD COMMIT.
Author: Tim Jarratt and Zach Robinson <[email protected]>
Date:   Fri Jan 31 15:59:46 2014 -0800

    Revert "Change command and advisory color."

    This reverts commit 9db9f0fab298e2a1c597933ed78fc42f8bfc2920.

commit 9db9f0fab298e2a1c597933ed78fc42f8bfc2920
Author: Tim Jarratt and Zach Robinson <[email protected]>
Date:   Fri Jan 31 15:28:38 2014 -0800

    Change command and advisory color.

commit 5418dba9773c844978a35d9831a6c565ca32d1b5
Author: Tim Jarratt and Zach Robinson <[email protected]>
Date:   Fri Jan 31 12:24:22 2014 -0800

    'cf push' should merge manifest env vars with server env vars

    [Finishes #64882714]

from cli.

Yes, I now see where you mentioned that you had to build from source, @simonjohansson. My apologies. Are you still seeing the bug with the downloaded binary?

@wdneto, I think we removed the raw binary when we had to yank libyaml due to licensing concerns. We're now building specific binaries for each our target platforms… I'll check with the team to see if we can ship a generic *nix binary.

from cli.

@scottruitt
Using the packaged binary from the dpkg package has the same bug for me. Im going to try the rpm binary aswell.

➜  ~  cf --version
cf version 6.0.0-90db382
➜  ~  cf delete-route cf.modomain.com -n myapp
Really delete route myapp.cf.mydomain.com?> y
Deleting route myapp.cf.mydomain.com...
[nothing]

Also, I'm curious to why the packaged version(which should be build form HEAD[1] on 6.0.0[2]) seems to differ from a actually version reported from --version[3]. A bit unsettling.

Thanks for your quick response!

[1] 74c3f72
[2] https://github.com/cloudfoundry/cli/commits/v6.0.0
[3] 90db382

Edit, the RPM contains a version thats build on [3] aswell.

from cli.

@simonjohansson We'll take a look at this bug this week. iirc, we reverted the commit but shipped from that sha without it, correct?

from cli.

Hi @simonjohansson,

We've added links to the raw v6.0.0 binaries on the README.

Regarding your issue with delete-route, could you re-run the commands with trace enabled? For ruby cf, do this using the --trace flag, and for cf 6.0.0, set the environment variable CF_TRACE=true. Could you put the output of these commands into a gist? You may want to review the output and remove any secret tokens or access keys (although both releases should theoretically hide these). Thanks!

• max and @sclevine

from cli.

@simonjohansson @wdneto we've added the raw binaries to the v6 release: https://github.com/cloudfoundry/cli/releases/tag/v6.0.0

we're also planning a v6.0.1 release with your fix. shouldn't be more than a few days before that goes out.

thanks again!

from cli.

👍

from cli.

@scottruitt @maxbrunsfeld
Cheers! Ill post the trace first thing back to work tomorrow morning.

from cli.

Re: "The version number in your cf v6 looks like an old one (I recall an old bug that omitted the actual SHA and just showed the string 'SHA')"

I figure out why the version of my home built binary of cf was "6.0.0-SHA", its because I didn't run ./bin/replace-sha before ./bin/build.

from cli.

Happy friday y'all.

Here are two gists:

go, 6.0.0-6bb57fe form the tgz[1]
https://gist.github.com/simonjohansson/8998874
The last request/response keep looping.

gem, 5.4.7.rc1
https://gist.github.com/simonjohansson/8998968
The route gest deleted.

[1] https://github.com/cloudfoundry/cli/releases/download/v6.0.0/cf-linux-amd64.tgz

from cli.

Thanks @simonjohansson-
We have identified the issue: it appears that the Cloud Controller that you are using has a problem with its job queue, preventing asynchronous jobs from running. The ruby CLI uses the synchronous version of this API, while the new CLI uses the async version. Previously, the CLI did not have a timeout for async requests; it would poll forever waiting for the CC to finish the requests. Our fix in the CLI for this issue was to introduce a timeout.

We don't know what is going on with your Cloud Controller server, but you may want to submit an issue to the cloud controller repository.
Thanks!

• max and @khwang1

from cli.

@maxbrunsfeld thank you!

from cli.

did this fix resolve the issue for you, @simonjohansson?

from cli.

@scottruitt I haven't had time to look more into this. Going to try to resolve it this week, if I fail I shall open a issue in the cc repo.

Since this seems to be an issue in my setup rather than cli I shall close it.

Thanks guys! :)

from cli.

I've just deployed v158 (from scratch), and i'm running into the same problem. The route doesn't seem to get deleted.

Will have a look through CC and report back

from cli.

Thanks, @wdneto. lmk if we can help.

from cli.

Finally got around to checking this out and it turns out my deployment was missing the 'clock_global' job instance.
https://github.com/cloudfoundry/cf-release/blob/master/templates/cf-jobs.yml#L186-L200

As far as the cli goes, would it be worth having a CF_ASYNC flag that can be used to enable/disable synchronous calls?

from cli.

@wdneto fwiw, you're the first to ask for async enable / disable flag. i'll keep an eye out for other requests, but right now i don't think this is something we want to add to the cli. looks like more and more endpoints, like service creation for instance, are moving to async too.

from cli.

No problem, I don't mind either way. Just thought it was worth asking :-)

from cli.