cloudfoundry / cli Goto Github PK
View Code? Open in Web Editor NEWThe official command line client for Cloud Foundry
Home Page: https://docs.cloudfoundry.org/cf-cli
License: Apache License 2.0
The official command line client for Cloud Foundry
Home Page: https://docs.cloudfoundry.org/cf-cli
License: Apache License 2.0
Is there any chance to get the wizard like interface in the command line back, we had in the ruby client? The usage of the new push command is a real pain, or perhaps I am doing something wrong.
Any reason why -t is not available? Going the set environment variable way is ok, but not that comfortable using -t.
Version:
cf -v
cf version 6.0.0-SHA
In my attempts to specify a custom command on gcf push, I ended up with a crashing app each time. "gcf app" on another terminal session showed the app to be "crashing", but "gcf apps" showed the app as started.
$ gcf apps
Getting apps in org glyn / space glyn as [email protected]...
OK
name state instances memory disk urls
<...>
web-servlet-2-application started 1/1 512M 1G glyn-ws2.cfapps.io
[gnimac:scratch]$ gcf app web-servlet-2-application
Showing health and status for app web-servlet-2-application in org glyn / space glyn as [email protected]...
OK
state: started
instances: 0/1
usage: 512M x 1 instances
urls: glyn-ws2.cfapps.io
status since cpu memory disk
#0 crashing 2013-12-10 04:27:48 PM 0.0% 0 of 0 0 of 0
[gnimac:scratch]$ gcf apps
Getting apps in org glyn / space glyn as [email protected]...
OK
name state instances memory disk urls
<...>
web-servlet-2-application started 0/1 512M 1G glyn-ws2.cfapps.io
➜ ~ cf m
Getting services from marketplace...
FAILED
Error performing request: Get /v2/services?inline-relations-depth=1: unsupported protocol scheme ""
➜ ~ gcf m
Getting services from marketplace in org me / space test as admin...
OK
service plans description
datastax-cassandra-dedicated 3-servers, 5-servers Datastax Cassandra: is the right choice when you need scalability and high availability without compromising performance
etcd-dedicated 1-server, 3-servers, 5-servers etcd: A highly-available key value store for shared configuration and service discovery
etcd-dedicated-aws-ec2 1-server, 3-servers, 5-servers etcd: A highly-available key value store for shared configuration and service discovery, running on AWS EC2
redis-dedicated 1-server, 2-servers, 3-servers redis: An advanced key-value store, can contain strings, hashes, lists, sets and sorted sets.
➜ ~ cf -v
cf version 6.0.0-da41e01
➜ ~ gcf -v
gcf version 6.0.0.rc2-be756bb
We added the following method to loggregatorlib:
https://github.com/cloudfoundry/loggregatorlib/blob/master/logmessage/message.go#L26
Which was cribbed from the cli:
https://github.com/cloudfoundry/cli/blob/master/src/cf/commands/application/helpers.go?source=c#L93
It'd be nice to use the loggregatorlib version so the same "short name" is used everywhere.
$ go-cf push ghost -d cfapps.io -n ghost -i 1 -m 128M -s nodejs10 -c "npm start"
FAILED
Server error, status code: 404, error code: 0, message:
I used to be able to specify services to create (as well as bind) in a manifest, e.g.
services:
mysql:
label: cleardb
provider: cleardb
plan: spark
rabbit:
label: cloudamqp
provider: cloudamqp
plan: lemur
redis:
label: rediscloud
provider: garantiadata
plan: 20mb
Now I just get
$ CF_TRACE=true cf push
FAILED
Error reading manifest file:
Expected services to be a list of strings.
As I use a number of different CF environments during the course of my work, the cf targets
command is very useful, so I can display all the current targets that I'm set up for.
This subcommand doesn't seem to be available for gcf
.
$ cf push foo -p foo,jar -c "<a very long command>
FAILED
Server error, status code: 400, error code: 10004, message: The request is invalid
$ cf push foo -p foo,jar -c "<something shorter>
OK
The only difference is the length of the command. The error message doesn't tell me that's a problem but I infer it. Why would that be a problem anyway?
Try this
$ touch foo
$ jar -cfe foo.jar demo.Foo foo
$ cf push fooapp -p foo.jar
The app will fail to start (no surprise since there is no code in it), but it's impossible to know why from the command line. Using cf logs fooapp
you just get an endless trickle of "Instance (index 0) failed to start accepting connections". There are no cf files
to inspect. What happened to stdout and stderr?
Worker applications do not need URIs, and the presence of a URI tells the DEA to make sure the app is listening on the port, otherwise it fails its health check and the DEA kills it.
There's a great environment variable CF_COLOR for turing off colorizing. Can it be added to the "ENVIRONMENT_VARIABLES:" section?
When I specify a war file to push, its pushing the entire directory. Is this a change in behavior or broken?
The other interesting note is that it prints
gcf p snoop -p /Users/fraenkel/Desktop/snoop.war -m 512M -n mysnoop
Using manifest file /Users/fraenkel/Desktop/snoop.war
I specified a path to a war not the manifest.
Any clues what this means? Looks like it's a bug to me because the same app deployed with a different env var set works fine:
$ cf push foo -p foo.jar
...
Uploading foo...
Uploading app: 107.7M, 918 files
...
FAILED
Error performing request: Put https://api.run.pivotal.io/v2/apps/1932b9f4-44d9-4559-81d5-49f907d82913/bits?async=true: read /tmp/cf/requests_1390908330_1473617160: bad file descriptor
We noticed that some endpoints have a nicely formatted JSON response, while others do not.
cf curl /v2/services
=> nicely formatted JSON
cf curl /v2/service_brokers
=> unintelligible blob of JSON
On a fresh Cloud Foundry deployment, there are no usable organizations or spaces yet.
So the new "ops user" experience looks like:
$ gcf login -u admin -p eaa139af52343
API endpoint: http://api.107.20.148.206.xip.io
Warning: Insecure http API endpoint detected: secure https API endpoints are recommended
Authenticating...
OK
Select a space:
Space> test
FAILED
Error finding space test
Space test not found
There was a recent update that switched an lgpl go yaml parsing library for a cgo based one. This has broken using gcf from within a deployed app as it now requires a newer version of glibc (2.14) than is provided on the default bosh-lite environment.
Currently, getting and keeping up to date with gcf
is harder than it needs to be. It'd be great if, as a first start, gcf
was available from Homebrew.
I've created a Homebrew formula for the project that can be found here. The formula currently builds v6.0.0-beta
by default, but can be run with the brew install --HEAD gcf
command to build from master.
This formula needs to be contributed to the Homebrew team or alternately hosted in a tap such as https://github.com/pivotal/homebrew-tap. I'll be happy to do either if this isn't something that the project wants to keep up with.
For the last several builds of gcf (sorry, I don't know which revision this started at), gcf consistently reports that I have exceeded my organisation quota when attempting to push to run.pivotal.io.
Pushing the same app using the Ruby cf gem (using 5.4.5 currently) works fine. I have 1G of quota available.
Pushing the app with gcf with the memory and instances explicitly specified -i 1 -m 128M
succeeds.
Here's a trace of the failing push using just gcf push aphome
...
REQUEST:
GET /v2/spaces/b2b5bf5e-4760-4444-898d-494659a20f1a/apps?q=name%3Aaphome&inline-relations-depth=1 HTTP/1.1
Host: api.run.pivotal.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.0.0.rc2-1cb5b6e / darwin
RESPONSE:ESC
HTTP/1.1 200 OK
Content-Length: 107
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Thu, 23 Jan 2014 10:52:13 GMT
Server: nginx
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: d26593c6-6910-4c9c-9b98-888abcb9f545
{
"total_results": 0,
"total_pages": 0,
"prev_url": null,
"next_url": null,
"resources": [
]
}
Creating app aphome in org apiper-org / space development as [email protected]...
REQUEST:
POST /v2/apps?async=true HTTP/1.1
Host: api.run.pivotal.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.0.0.rc2-1cb5b6e / darwin
{"name":"aphome","space_guid":"b2b5bf5e-4760-4444-898d-494659a20f1a"}
RESPONSE:ESC
HTTP/1.1 400 Bad Request
Content-Length: 8873
Connection: keep-alive
Content-Type: application/json;charset=utf-8
Date: Thu, 23 Jan 2014 10:52:13 GMT
Server: nginx
X-Content-Type-Options: nosniff
X-Vcap-Request-Id: a1e543a8-bc1f-443d-98f7-bd452b568ddf
{"code":100005,"description":"You have exceeded your organization's memory limit.","error_code":"CF-AppMemoryQuotaExceeded","types":["AppMemoryQuotaExceeded","Error"],"backtrace":["/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/base.rb:98:in `rescue in dispatch'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/base.rb:93:in `dispatch'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb:16:in `block in define_route'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1540:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1540:in `block in compile!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:950:in `[]'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:950:in `block (3 levels) in route!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:966:in `route_eval'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/agent/instrumentation/sinatra.rb:133:in `route_eval_with_newrelic'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:950:in `block (2 levels) in route!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:987:in `block in process_route'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:985:in `catch'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:985:in `process_route'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/agent/instrumentation/sinatra.rb:116:in `process_route_with_newrelic'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:948:in `block in route!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:947:in `each'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:947:in `route!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1059:in `block in dispatch!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `block in invoke'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `catch'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `invoke'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1056:in `dispatch!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/agent/instrumentation/sinatra.rb:151:in `dispatch_and_notice_errors_with_newrelic'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/agent/instrumentation/sinatra.rb:146:in `block in dispatch_with_newrelic'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/agent/instrumentation/controller_instrumentation.rb:339:in `perform_action_with_newrelic_trace'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/agent/instrumentation/sinatra.rb:145:in `dispatch_with_newrelic'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:882:in `block in call!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `block in invoke'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `catch'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1041:in `invoke'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:882:in `call!'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:870:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/rack/error_collector.rb:50:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/rack/browser_monitoring.rb:23:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/newrelic_rpm-3.7.1.180/lib/new_relic/rack/agent_hooks.rb:28:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-protection-1.5.0/lib/rack/protection/xss_header.rb:18:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-protection-1.5.0/lib/rack/protection/path_traversal.rb:16:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-protection-1.5.0/lib/rack/protection/json_csrf.rb:18:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-protection-1.5.0/lib/rack/protection/base.rb:49:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-protection-1.5.0/lib/rack/protection/base.rb:49:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-protection-1.5.0/lib/rack/protection/frame_options.rb:31:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/nulllogger.rb:9:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/head.rb:11:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:175:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:1949:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/builder.rb:138:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/urlmap.rb:65:in `block in call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in `each'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/urlmap.rb:50:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/commonlogger.rb:33:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/sinatra-1.4.3/lib/sinatra/base.rb:212:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/rack-1.5.2/lib/rack/builder.rb:138:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/thin-1.5.1/lib/thin/connection.rb:81:in `block in pre_process'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/thin-1.5.1/lib/thin/connection.rb:79:in `catch'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/thin-1.5.1/lib/thin/connection.rb:79:in `pre_process'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.3/lib/eventmachine.rb:1037:in `call'","/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/vendor/bundle/ruby/1.9.1/gems/eventmachine-1.0.3/lib/eventmachine.rb:1037:in `block in spawn_threadpool'"]}
FAILED
Server error, status code: 400, error code: 100005, message: You have exceeded your organization's memory limit.
It used to be possible to push a single app from a manifest with multiple apps in it. This was incredibly useful, so please bring it back!
$ CF_TRACE=true cf push foo
Using manifest file .../manifest.yml
FAILED
Error: APP_NAME command line argument is not allowed when pushing multiple apps from a manifest file.
I experienced this with a bosh-lite deploy where I recreated my cf deployment from scratch. I targeted the api endpoint, logged in and it showed me that I was in the "myorg" org and the "myspace" space, but on the fresh install these did not yet exist. Executing a command such as gcf apps resulted in an error:
± |master ✗| → gcf apps
Getting apps in org myorg / space myspace as admin...
FAILED
Server error, status code: 404, error code: 40004, message: The app space could not be found: c39abbfa-f8f9-4e7a-b2bf-debca93956da
I noticed that when I was testing my "enabled" feature, the existing position flag (-i) on update-buildpack is always sending 0 which screws things up.
The only solution I can think of is to have codegansta/cli expose a way to locate actual flags to handle these truly optional flags.
If a custom command such as the following is required:
JAVA_HOME=$PWD/.openjdk JAVA_OPTS="-Dhttp.port=$PORT -Djava.io.tmpdir=$TMPDIR -XX:MaxPermSize=64M -XX:OnOutOfMemoryError=$PWD/.openjdk/bin/killjava -XX:PermSize=64M -Xms382293K -Xmx382293K -Xss995K" .tomcat/bin/catalina.sh run
passing this using the -c option of gcf is unusable. U*X is renowned for escaping difficulties and certainly it's a major headache to correctly escape a command such as the one above.
If I want to tail the logs of a push request and ensure I see the first log, I have a problem. gcf logs --recent may miss early logs whereas gcf logs issued (to start tailing early) before the push fails because the application doesn't yet exist.
So I am forced to kick off the push, switch to another terminal, and repeatedly issue gcf logs in the hope that I will win the race and capture the first log.
I suggest that an option be added to gcf push to intersperse the tailed logs with the current push output (like cf used to do) or that gcf logs be allowed to wait for an application to be created (although the latter will find itself in a similar race to the one above, so is probably not a great solution).
Running cf version 6.0.0-SHA.
Checkout the 6.0.0 tag and compiled on my machine since there is no installer for Arch Linux.
Running
cf delete-route cf.mydomain.com -n myapp
just stalls, looking at the logs in my syslog machine I see
root@468cb83f-83a8-46c1-ac42-ec23ab928787:/var/vcap/store/log# pwd
/var/vcap/store/log
root@468cb83f-83a8-46c1-ac42-ec23ab928787:/var/vcap/store/log# grep delete -R *
cloud_controller_ng/2014/02/11/cloud_controller_ng.log:172.30.5.63 -- {"timestamp":1392137894.0701954,"message":"dispatch VCAP::CloudController::RoutesController delete /v2/routes/:guid","log_level":"debug","source":"cc.api","data":{"request_guid":"7e32be19-86ba-456c-bd92-9565c0927854"},"thread_id":38987240,"fiber_id":39199540,"process_id":15640,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb","lineno":12,"method":"block in define_route"}
cloud_controller_ng/2014/02/11/cloud_controller_ng.log:172.30.5.63 -- {"timestamp":1392137894.0707784,"message":"cc.dispatch","log_level":"debug","source":"cc.api","data":{"request_guid":"7e32be19-86ba-456c-bd92-9565c0927854","endpoint":"delete","args":["405d9fee-75f7-497e-9dac-860491bfca2c"]},"thread_id":38987240,"fiber_id":39199540,"process_id":15640,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/base.rb","lineno":93,"method":"dispatch"}
With the gem, 5.4.7.rc1
cf delete-route myapp.cf.mydomain.com
The route gets deleted properly.
Looking at the logs again i see
cloud_controller_ng/2014/02/11/cloud_controller_ng.log:172.30.5.63 -- {"timestamp":1392138304.381838,"message":"dispatch VCAP::CloudController::RoutesController delete /v2/routes/:guid","log_level":"debug","source":"cc.api","data":{"request_guid":"ffa1f085-8f04-4f81-a851-a796c657ec87"},"thread_id":38959060,"fiber_id":40149640,"process_id":15640,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/routes.rb","lineno":12,"method":"block in define_route"}
cloud_controller_ng/2014/02/11/cloud_controller_ng.log:172.30.5.63 -- {"timestamp":1392138304.3824947,"message":"cc.dispatch","log_level":"debug","source":"cc.api","data":{"request_guid":"ffa1f085-8f04-4f81-a851-a796c657ec87","endpoint":"delete","args":["405d9fee-75f7-497e-9dac-860491bfca2c"]},"thread_id":38959060,"fiber_id":40149640,"process_id":15640,"file":"/var/vcap/packages/cloud_controller_ng/cloud_controller_ng/lib/cloud_controller/rest_controller/base.rb","lineno":93,"method":"dispatch"}
$ gcf map start start spring.io
Unknown domain 'spring.io'.
The domain is available in the current org and apparently gcf rc1 did it correctly. (The ruby gem fails in the same way at version 5.4.5.)
$ gcf bind-service sinatra mypg
Binding service mypg to app sinatra in org altoros / space conferences as admin...
OK
TIP: Use 'cf push' to ensure your env variable changes take effect
I have setup a devbox via nise_installer and I am using my cfmc frontend to create orgs and spaces, which works as expected. Using the new Go Client results in den following errors, when setting the target:
cf target -o services
FAILED
Could not target org.
Server error, status code: 404, error code: 10000, message: Unknown request
The login though works:
cf login
API endpoint: http://api.172.16.56.167.xip.io/
Warning: Insecure http API endpoint detected: secure https API endpoints are recommended
Username> admin
Password>
Authenticating...
OK
FAILED
Error finding avilable orgs
Server error, status code: 404, error code: 10000, message: Unknown request
What makes be wonder is the missing API version tag when doing:
cf target
API endpoint: http://api.172.16.56.167.xip.io/ (API version: )
User: admin
Anything I am doing wrong?
the gcf client is passing credentials directly to uaa.config.AuthorizationEndpoint/oauth/token which is bypassing custom profiles like LDAP.
This error occurred:
NewMap called with unexpected argument
and this stack trace:
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/main/cf.go:142 (0x41d25f)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/main/cf.go:29 (0x41d654)
/usr/local/go/src/pkg/runtime/panic.c:248 (0x430196)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/generic/map.go:135 (0x4fb276)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/manifest/manifest_disk_repository.go:88 (0x4b8473)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/manifest/manifest_disk_repository.go:48 (0x4b7f22)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/manifest/manifest_disk_repository.go:28 (0x4b7cbf)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/manifest/manifest.go:1 (0x4b98de)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/commands/application/push.go:431 (0x5bf099)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/commands/application/push.go:390 (0x5be969)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/commands/application/push.go:68 (0x5ba9b2)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/commands/runner.go:52 (0x4abf5d)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/commands/api.go:1 (0x4b0cd6)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/cf/app/app.go:496 (0x49888c)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/github.com/codegangsta/cli/command.go:73 (0x4df854)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/github.com/codegangsta/cli/app.go:101 (0x4deaa4)
/home/ubuntu/jenkins-slave/workspace/go-cli-tests-linux-64/src/main/cf.go:66 (0x41cf9d)
/usr/local/go/src/pkg/runtime/proc.c:220 (0x431f6f)
/usr/local/go/src/pkg/runtime/proc.c:1394 (0x434490)
I guess I'm just not cool because I don't use a black terminal, but the output from "gcf apps" etc. is unreadable on a white background. It's quite easy to fix I would have thought (just use different non-grey colours). The same as the old ruby client would work for me.
$ gcf login
API endpoint> run.pivotal.io^^^^
...
^^^
Increasingly frustrated me trying to hit left arrow
to go back to start of line.
What would be really useful would be something that respects normal bash behaviour (e.g. ctrl-A for start of line).
When the org-users
command runs, it gets the organization guid by calling FindByName
on the organization repository. The current FindByName
code is using inline-releations-depth=1
which, in addition to returning the org guid, returns all of the users, managers, billing managers, and auditors.
The user information from the initial request is discarded and then additional requests are made to get the user guids by querying the managers, billing managers, and auditors endpoints. For large organizations, this results in a significant amount of wasted data retrieval and DB queries.
It seems like the initial org query shouldn't be using inline-relations-depth=1
for this path and it probably makes sense to review other paths as well.
GET /v2/organizations?q=name%3Aplayground&inline-relations-depth=1 HTTP/1.1
GET /v2/organizations/7a77ded9-f8eb-4355-967e-2e68eb2e72be/managers HTTP/1.1
GET /v2/organizations/7a77ded9-f8eb-4355-967e-2e68eb2e72be/billing_managers HTTP/1.1
GET /v2/organizations/7a77ded9-f8eb-4355-967e-2e68eb2e72be/auditors HTTP/1.1
From Announcing Cloud Foundry cf v6:
Written to be scripted
Part of being able to "script" gcf
means being able to get the output of a command in a form easily digested by a script. Eg, JSON. Currently, I don't see how to do that.
It's nice that the output is going to stdout now - I think some of it used to go to tty and couldn't be captured at all. But redirecting gcf apps
, for instance, shows interesting bits interspersed with ansi sequences, fixed white-space for columnizing, etc. It could be scraped, but who wants to do that?
$ gcf api api.run.pivotal.io
Setting api endpoint to api.run.pivotal.io...
OK
API endpoint: https://api.run.pivotal.io (API version: 2.0.0)
Logged out, use 'gcf login USERNAME' to login
$ gcf login [email protected]
API endpoint: https://api.run.pivotal.io
Username>
If a server side error occurs when uploading new application or buildpack bits, resulting in a 4xx error code (for example), the cli thinks the operation succeeded.
The problem is caused by the use of fileutils.TempFile
in both src/cf/api/application_bits.go
and src/cf/api/buildpack_bits.go
.
TempFile
requires the caller to provide a callback function. The actual http request is made within the callback, but this is asynchronous to when the caller has returned.
This means the caller returns with a blank apiResponse
object, which is interpreted as successful - and no errors are passed back.
The fix is to either move to a promise-like api for deferred resolution of the function call, or remove the use of callbacks in the TempFile
api (which I don't see any benefits of in the current implementation).
I'm happy to put together a PR, but wanted get input on which way you'd like to resolve this.
gcf version 6.0.0.rc2-f1f135ad44
gcf logs (and log output during a gcf push) attempts to use secure sockets on TCP4443.
This seems to be hard coded, instead of checking for a defined url from the CC API such as; "logging_endpoint":"wss://loggregator.someurl.net:443" in /v2/info
Line 134 in e99c9b9
I think the way I read the manifests code we are parsing the manifest file into a generic.Map, rather than a (normal) golang type struct (nested as necessary). How come? Isn't there a schema for the manifest that could be explicitly coded as a type struct?
When debugging a crashing application, it would be very helpful to be able to download some of the droplet's files using gcf files. However, when I try this I consistently get 503's or other errors. I have never succeeded in downloading any files.
This would be useful for grabbing staging_info.yml, env.log, and the Java buildpack's diagnostic log during the push, especially when the push is in "crashing" mode for several minutes (after which no files can be deleted because the application failed to start).
(Sorry if this is a backend issue, but it's something I've become aware of since starting to use gcf, mainly because of the difficulty of getting a custom command accepted correctly, although that is being fixed in another issue.)
As noted in issue #42, gcf is using the go.net websocket code to connect to the loggregator directly and does not support connections through a proxy server.
GCF v6 -74c3f72
nyet - master a380af28e0d4c2a26ff9701235d0e9259d8632e3
CF client - 5.4.5
CloudFoundry - cf-154.yml
deploying the NYET test app - JavaTinyApp-1.1.war
cf logs JavaTinyApp-1.1.war
results in
Using manifest file manifest.yml
Getting logs for JavaTinyApp-1.1.war #0... OK
Reading logs/env.log... OK
TMPDIR=/home/vcap/tmp
VCAP_APP_PORT=61019
USER=vcap
VCAP_APPLICATION={"instance_id":"75e5ee3efc0e4099b0354025a0303963","instance_index":0,"host":"0.0.0.0","port":61019,"started_at":"2014-02-05 10:59:10 +0000","started_at_timestamp":1391597950,"start":"2014-02-05 10:59:10 +0000","state_timestamp":1391597950,"limits":{"mem":256,"disk":1024,"fds":16384},"application_version":"42830e43-fa67-424a-aa92-0e89bd287700","application_name":"JavaTinyApp-1.1.war","application_uris":["tinyjava.cf.c3ci.cpgpaas.net"],"version":"42830e43-fa67-424a-aa92-0e89bd287700","name":"JavaTinyApp-1.1.war","uris":["tinyjava.cf.c3ci.cpgpaas.net"],"users":null}
PATH=/bin:/usr/bin
PWD=/home/vcap
VCAP_SERVICES={}
SHLVL=1
HOME=/home/vcap/app
PORT=61019
VCAP_APP_HOST=0.0.0.0
MEMORY_LIMIT=256m
_=/usr/bin/env
Reading logs/staging_task.log... OK
-----> Downloaded app package (8.0K)
-----> Downloading OpenJDK 1.7.0_51 from http://download.pivotal.io.s3.amazonaws.com/openjdk/lucid/x86_64/openjdk-1.7.0_51.tar.gz (7.6s)
Expanding JRE to .java (1.6s)
-----> Downloading Tomcat 7.0.50 from http://download.pivotal.io.s3.amazonaws.com/tomcat/tomcat-7.0.50.tar.gz (4.0s)
Expanding Tomcat to .tomcat (0.2s)
-----> Downloading Buildpack Tomcat Support 1.1.1 from http://download.pivotal.io.s3.amazonaws.com/tomcat-buildpack-support/tomcat-buildpack-support-1.1.1.jar (0.2s)
Reading logs/stderr.log... OK
Feb 05, 2014 10:59:14 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-61019"]
Feb 05, 2014 10:59:14 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 868 ms
Feb 05, 2014 10:59:14 AM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Feb 05, 2014 10:59:14 AM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.50
Feb 05, 2014 10:59:14 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /home/vcap/app/.tomcat/webapps/ROOT
Feb 05, 2014 10:59:15 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-61019"]
Feb 05, 2014 10:59:15 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 1209 ms
Reading logs/stdout.log... OK
With GCF
gcf logs JavaTinyApp-1.1.war
we get
FAILED
Loggregator endpoint missing from config file
This causes the NYET tests to fail with
Loggregator
--- find: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'> (regular user: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'>)
DEPRECATION WARNING: Please use CFoundry::Client.get instead of CFoundry::Client.new
--- create: #<CFoundry::V2::Organization '605d652a-3f33-4386-8974-a6e600ce0709'> (*admin* user: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'>)
--- create: #<CFoundry::V2::Space '6de4a0a7-8299-4f15-b6a1-716e08ef12cf'> (regular user: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'>)
--- create: #<CFoundry::V2::App '2df0c66b-2286-4c21-bbdb-47a4808d0e92'> (regular user: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'>)
--- create: #<CFoundry::V2::Route 'c6ad6261-2b8f-4df7-94db-701cbf891c41'> (regular user: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'>)
starting deploy_app (2014-02-05 12:36:22 +0000)
starting start_app_and_wait_until_up (2014-02-05 12:36:22 +0000)
starting wait_until_app_started (2014-02-05 12:37:05 +0000)
--- Started monitoring loggregator_works of application.
starting check_loggregator_works (2014-02-05 12:37:12 +0000)
--- Metric loggregator.health = 0 ({})
--- delete: #<CFoundry::V2::Organization '605d652a-3f33-4386-8974-a6e600ce0709'> (*admin* user: #<CFoundry::V2::User '2b44ee8d-e05b-4541-8a88-54f5ad148e31'>)
gets log messages from an app (FAILED - 1)
DogapiMonitoring
#record_action
given a deployment without a 'cf-' prefix
--- Started monitoring action of application.
--- Finished monitoring action of application. Took 0.0 seconds.
--- Dogapi record 'nyet.action.response_time_ms' with 0.0040531158447265625 ["role:core", "deployment:cf-deployment_name", "app_type:app_type"]
prepends 'cf-' to the deployment name
given a deployment with a 'cf-' prefix
--- Started monitoring action of application.
--- Finished monitoring action of application. Took 0.0 seconds.
--- Dogapi record 'nyet.action.response_time_ms' with 0.0030994415283203125 ["role:core", "deployment:cf-deployment_name", "app_type:app_type"]
does not prepend 'cf-' to the deployment name
Monitoring
#record_action
when block raises an error
propagates raised error
when block does not raise an error
returns time
Failures:
1) Loggregator gets log messages from an app
Failure/Error: runner.should say "Connected, tailing logs for app #{app_name}"
expected 'Connected, tailing logs for app loggregator-java' to be printed, but it wasn't. full output:
FAILED
Loggregator endpoint missing from config file
# ./spec/loggregator_spec.rb:58:in `block (2 levels) in check_loggregator_works'
# ./spec/loggregator_spec.rb:57:in `block in check_loggregator_works'
# ./spec/loggregator_spec.rb:56:in `new'
# ./spec/loggregator_spec.rb:56:in `check_loggregator_works'
# ./spec/loggregator_spec.rb:39:in `block (3 levels) in <top (required)>'
# ./spec/support/monitoring.rb:5:in `call'
# ./spec/support/monitoring.rb:5:in `record_action'
# ./spec/loggregator_spec.rb:37:in `block (2 levels) in <top (required)>'
# ./spec/support/user_with_org.rb:43:in `block (2 levels) in with_time_limit'
# ./spec/support/user_with_org.rb:42:in `block in with_time_limit'
Finished in 3 minutes 9 seconds
6 examples, 1 failure
Failed examples:
rspec ./spec/loggregator_spec.rb:21 # Loggregator gets log messages from an app
/Users/pivotal/.rvm/rubies/ruby-1.9.3-p392/bin/ruby -S rspec ./spec/app_crud_spec.rb ./spec/loggregator_spec.rb ./spec/support_spec/dogapi_monitoring_spec.rb ./spec/support_spec/monitoring_spec.rb --format documentation --color failed
When you give a cf push <>.war and select an subdomain for example "api" and the normal domain (i.e. your xip.io IP) then the app will be deployed and the dns-name of your api-host is overwritten! So a normal user can kill your entire cf just by pushing an app with the same name as one of your cf-core components.
As a result you get always messages like this when you make a cf apps / cf services and of course you service-gateway can't connect anymore and so on...
CFoundry::NotFound: 404: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /v2/spaces/605fdc95-cdc4-46db-9967-e5cd507cc5e6 was not fou nd on this server.</p>
</body></html>
It's tough to tell if a box has an old version (beta 1) of the CLI or the new one (beta 2) with working loggregator support.
We have an expanded WAR which succeeds with cf and gcf (on OSX), but fails on Windows.
The only piece that looks like an issue is during the application upload where I see
[{"fn":"WEB-INF\classes\com\ibm\app\webcontainer\snoop\SnoopServlet.class","sha1":"5d94f0c514a709a1aa8485ace5b47efb017df061","size":9
173},{"fn":"WEB-INF\web.xml"
Shouldn't this be normalize to Unix?
It would to be nice to parse arrays for string and int types
example:
./app create -dns 8.8.8.8 -dns 8.8.4.4 server.domain.tld
something like :
cli.ArrayStringFlag{"dns", "8.8.8.8", "set one or more dns Servers"}
Thanks in advance for this awesome app
When using gcf space-users, there is an error if you are logged in as someone who is not an admin:
gcf space-users [email protected] extend-collaborative-niches
Getting users in org [email protected] / space extend-collaborative-niches as [email protected]
SPACE MANAGER
FAILED
Failed fetching space-users for role Server error, status code: 403, error code: access_denied, message: Access is denied.
SPACE MANAGER
The CLI seems to be using the current users token to hit UAA for the username/information about the entry in CC, which is not allowed for non-admins. A quick fix would be to use a token for the CLI to get this information, however this could be a security risk. Perhaps the permissions for UAA should be looked at.
How do you do it, if it's not like in the docs (http://docs.cloudfoundry.com/docs/using/managing-apps/cf/#switch-space)?
✗ go-cf push ghost -d cfapps.io -n ghost -i 1 -m 128M -s nodejs10 -c "npm start"
Uploading ghost...
FAILED
Server error, status code: 504, error code: 0, message:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.