|
Re: CF rollback issue from v210 to v202
Thanks a lot James. we will try it out.
toggle quoted message
Show quoted text
On Tue, Jun 30, 2015 at 12:54 AM, James Bayer <jbayer(a)pivotal.io> wrote: if you backup the databases before the upgrade, then you could restore the
databases before the rollback deployment. we don't ever rollback at
pivotal, we roll forward with fixes. i recommend testing upgrades in a test
environment to gain confidence. rolling back would be an absolute worst
case.
On Mon, Jun 29, 2015 at 4:18 PM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:
Hi James,
Thanks a lot , Please could you tell us what is the clean way of doing
rollback from v210 to v202.
Regards
Lingesh M
On Mon, Jun 29, 2015 at 5:58 PM, James Bayer <jbayer(a)pivotal.io> wrote:
when you upgrade to a newer version of cf-release, it performs database
migrations. the message is likely telling you that cf-release v202 code in
the cloud controller is not compatible with the db migrations that were
performed when upgrading to cf-release v210.
On Mon, Jun 29, 2015 at 2:53 PM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:
Hello Team ,
we are able to upgrade cf 202 to v210 in development environment ,
incase of any unknown issue we may want to rollback to 202. So we are
trying to rollback from 210 to 202. But bosh not able to complete the
rollback successfully. we are getting below error from bosh.
Error :
Started updating job api_z1
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0'
is not running after update (00:14:53)
Error 400007: `api_z1/0' is not running after update
even we are able to ssh on api_z1 successfully. but found below issue
in cloud_controller_ng .
monit summary
The Monit daemon 5.2.4 uptime: 13m
Process 'cloud_controller_ng' Execution failed
Process 'cloud_controller_worker_local_1' not monitored
Process 'cloud_controller_worker_local_2' not monitored
Process 'nginx_cc' not monitored
Process 'metron_agent' running
Process 'check_mk' running
System 'system_6e1e4d43-f677-4dc6-ab8a-5b6152504918' running
logs from : /var/vcap/sys/log/cloud_controller_ng_ctl.err.log
[2015-06-29 21:18:55+0000] Tasks: TOP => db:migrate
[2015-06-29 21:18:55+0000] (See full trace by running task with --trace)
[2015-06-29 21:19:39+0000] ------------ STARTING
cloud_controller_ng_ctl at Mon Jun 29 21:19:36 UTC 2015 --------------
[2015-06-29 21:19:39+0000] rake aborted!
[2015-06-29 21:19:39+0000] Sequel::Migrator::Error: Applied migration
files not in file system:
20150306233007_increase_size_of_delayed_job_handler.rb,
20150311204445_add_desired_state_to_v3_apps.rb,
20150313233039_create_apps_v3_routes.rb,
20150316184259_create_service_key_table.rb,
20150318185941_add_encrypted_environment_variables_to_apps_v3.rb,
20150319150641_add_encrypted_environment_variables_to_v3_droplets.rb,
20150323170053_change_service_instance_description_to_text.rb,
20150323234355_recreate_apps_v3_routes.rb,
20150324232809_add_fk_v3_apps_packages_droplets_processes.rb,
20150325224808_add_v3_attrs_to_app_usage_events.rb,
20150327080540_add_cached_docker_image_to_droplets.rb,
20150403175058_add_index_to_droplets_droplet_hash.rb,
20150403190653_add_procfile_to_droplets.rb,
20150407213536_add_index_to_stack_id.rb,
20150421190248_add_allow_ssh_to_app.rb, 20150422000255_route_path_field.rb,
20150430214950_add_allow_ssh_to_spaces.rb,
20150501181106_rename_apps_allow_ssh_to_enable_ssh.rb,
20150514190458_fix_mysql_collations.rb,
20150515230939_add_case_insensitive_to_route_path.rb
cloud_controller_ng_ctl.err.log
Please any idea is some thing problem with rollback scripts during
rollback ??.
Regards
Lingesh M
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: When will diego release?
Balaramaraju JLSP <balaramaraju@...>
Hi All,
Dose this mean Garden Container [windows] will be available along with
Diego ?
Thanks
balaramaraju
toggle quoted message
Show quoted text
On Mon, Jun 29, 2015 at 8:53 PM, James Bayer <jbayer(a)pivotal.io> wrote: looking at the public tracker for diego, you can track as the team
approaches this important release marker [1] named "Diego can replace DEAs".
pivotal is using diego in our hosted production envs for a portion of our
traffic today. we have a projected plan to switch over completely in the
mid/late august time frame.
[1] https://www.pivotaltracker.com/story/show/76376202
On Sun, Jun 28, 2015 at 8:39 PM, libnux <libnux.me(a)gmail.com> wrote:
Hi,
We're going to use diego in production. Could you please give the date of
the first formal release?
Thanks.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
J L S P Balaramaraju
|
|
|
Re: CF rollback issue from v210 to v202
if you backup the databases before the upgrade, then you could restore the databases before the rollback deployment. we don't ever rollback at pivotal, we roll forward with fixes. i recommend testing upgrades in a test environment to gain confidence. rolling back would be an absolute worst case. On Mon, Jun 29, 2015 at 4:18 PM, Lingesh Mouleeshwaran < lingeshmouleeshwaran(a)gmail.com> wrote: Hi James,
Thanks a lot , Please could you tell us what is the clean way of doing
rollback from v210 to v202.
Regards
Lingesh M
On Mon, Jun 29, 2015 at 5:58 PM, James Bayer <jbayer(a)pivotal.io> wrote:
when you upgrade to a newer version of cf-release, it performs database
migrations. the message is likely telling you that cf-release v202 code in
the cloud controller is not compatible with the db migrations that were
performed when upgrading to cf-release v210.
On Mon, Jun 29, 2015 at 2:53 PM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:
Hello Team ,
we are able to upgrade cf 202 to v210 in development environment ,
incase of any unknown issue we may want to rollback to 202. So we are
trying to rollback from 210 to 202. But bosh not able to complete the
rollback successfully. we are getting below error from bosh.
Error :
Started updating job api_z1
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is
not running after update (00:14:53)
Error 400007: `api_z1/0' is not running after update
even we are able to ssh on api_z1 successfully. but found below issue in
cloud_controller_ng .
monit summary
The Monit daemon 5.2.4 uptime: 13m
Process 'cloud_controller_ng' Execution failed
Process 'cloud_controller_worker_local_1' not monitored
Process 'cloud_controller_worker_local_2' not monitored
Process 'nginx_cc' not monitored
Process 'metron_agent' running
Process 'check_mk' running
System 'system_6e1e4d43-f677-4dc6-ab8a-5b6152504918' running
logs from : /var/vcap/sys/log/cloud_controller_ng_ctl.err.log
[2015-06-29 21:18:55+0000] Tasks: TOP => db:migrate
[2015-06-29 21:18:55+0000] (See full trace by running task with --trace)
[2015-06-29 21:19:39+0000] ------------ STARTING cloud_controller_ng_ctl
at Mon Jun 29 21:19:36 UTC 2015 --------------
[2015-06-29 21:19:39+0000] rake aborted!
[2015-06-29 21:19:39+0000] Sequel::Migrator::Error: Applied migration
files not in file system:
20150306233007_increase_size_of_delayed_job_handler.rb,
20150311204445_add_desired_state_to_v3_apps.rb,
20150313233039_create_apps_v3_routes.rb,
20150316184259_create_service_key_table.rb,
20150318185941_add_encrypted_environment_variables_to_apps_v3.rb,
20150319150641_add_encrypted_environment_variables_to_v3_droplets.rb,
20150323170053_change_service_instance_description_to_text.rb,
20150323234355_recreate_apps_v3_routes.rb,
20150324232809_add_fk_v3_apps_packages_droplets_processes.rb,
20150325224808_add_v3_attrs_to_app_usage_events.rb,
20150327080540_add_cached_docker_image_to_droplets.rb,
20150403175058_add_index_to_droplets_droplet_hash.rb,
20150403190653_add_procfile_to_droplets.rb,
20150407213536_add_index_to_stack_id.rb,
20150421190248_add_allow_ssh_to_app.rb, 20150422000255_route_path_field.rb,
20150430214950_add_allow_ssh_to_spaces.rb,
20150501181106_rename_apps_allow_ssh_to_enable_ssh.rb,
20150514190458_fix_mysql_collations.rb,
20150515230939_add_case_insensitive_to_route_path.rb
cloud_controller_ng_ctl.err.log
Please any idea is some thing problem with rollback scripts during
rollback ??.
Regards
Lingesh M
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- Thank you, James Bayer
|
|
|
Re: Document for service broker api version 2.5
NGUYEN Hong Chau <nguyenhongchau@...>
Thank Shannon for your detailed explanation. It is really useful for us.
Have a good day,
Regards,
--
NGUYEN Hong Chau
toggle quoted message
Show quoted text
On Tue, Jun 30, 2015 at 5:31 AM, Shannon Coen <scoen(a)pivotal.io> wrote: Nguyen,
The cause of your error is explained here:
App Log Streaming -
http://docs.cloudfoundry.org/services/app-log-streaming.html
Your broker is returning syslog_drain_url in response to a bind request,
but has not declared requires:syslog_drain in the catalog endpoint.
Catalog: http://docs.cloudfoundry.org/services/api.html#catalog-mgmt
Response Body
services.requires - A list of permissions that the user would have to give
the service, if they provision it. The only permission currently supported
is syslog_drain.
Binding: http://docs.cloudfoundry.org/services/api.html#binding
Response Body
syslog_drain_url - A URL to which Cloud Foundry should drain logs to for
the bound application.
I noticed that in our description for the syslog_drain_url field, we
should probably also refer to the requires field. I'll update the docs.
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Mon, Jun 29, 2015 at 3:04 AM, NGUYEN Hong Chau <
nguyenhongchau(a)gmail.com> wrote:
Thank James and Shannon for your answer,
The support for the Arbitrary Parameters feature is actually a great
improvement for service broker. I'm really wish to test it soon.
Now when i'm implementing my service broker, the operation fails at
binding the created service instance to an application:
"FAILED
Server error, status code: 502, error code: 10001, message: The service
is attempting to stream logs from your application, but is not registered
as a logging service. Please contact the service provider."
I'll try to check the logs from brokers and controller,
Regards,
--
NGUYEN Hong Chau
On Fri, Jun 26, 2015 at 11:57 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
Hello,
A commit to increment the broker API version header went out by mistake.
We are currently backfilling docs for 2.5 (should be published very soon):
https://www.pivotaltracker.com/story/show/88824286
Broker API v2.5 represents support for the Arbitrary Parameters feature.
Cloud Controller may include a field called "parameters" in the provision,
update, and bind request bodies. Values for this field are only included if
provided by the CF API client (CLI, etc).
These changes are expected to be backwards compatible. A broker that
does not support the "parameters" field should ignore it.
Info that could help troubleshoot:
- what operation fails; create/update broker, provision, bind, etc?
- logs from the broker of the request and response
- logs from cloud controller of the request and response to the broker
- output of CLI with CF_TRACE=true
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Thu, Jun 25, 2015 at 8:26 PM, James Bayer <jbayer(a)pivotal.io> wrote:
looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html
2.5 should only have been incremental changes and should be backward
compatible with other 2.x versions.
when you say it doesn't work, do you have details of an interaction
that shows the problem?
On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <
nguyenhongchau(a)gmail.com> wrote:
Hi all,
I'm trying to implement a service broker for cf-release v210. I
implemented my service broker in cf-release v207 based on this service
broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code
doesn't work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?
Thanks in advance.
--
Nguyen Hong-Chau
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Nguyen Hong-Chau
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Nguyen Hong-Chau
|
|
|
Re: Can't create/update buildpacks, "a filename must be specified"
Matthew Sykes <matthew.sykes@...>
You may need to supply your access log from the nginx in front of cc or the
cc log because when I create a new buildpack, it's working just fine:
$ CF_TRACE=true cf create-buildpack test-binary-bp
./binary_buildpack-cached-v1.0.1.zip 1 --enable
VERSION:
6.11.3-cebadc9
Creating buildpack test-binary-bp...
REQUEST: [2015-06-29T20:10:37-04:00]
POST /v2/buildpacks?async=true HTTP/1.1
Host: api.10.244.0.34.xip.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: application/json
User-Agent: go-cli 6.11.3-cebadc9 / darwin
{"name":"test-binary-bp","position":1,"enabled":true}
RESPONSE: [2015-06-29T20:10:37-04:00]
HTTP/1.1 201 Created
Content-Length: 337
Content-Type: application/json;charset=utf-8
Date: Tue, 30 Jun 2015 00:10:37 GMT
Location: /v2/buildpacks/16e73f3c-3980-4603-ba07-8e5b08b78f7b
Server: nginx
X-Cf-Requestid: 49dc1a83-c37a-4311-66e5-5d2a2aea5df3
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
c7ac7b0c-9261-4b2b-7df6-d7788ba26827::168b561c-4e58-4f7c-9bf4-50ac6589522c
{
"metadata": {
"guid": "16e73f3c-3980-4603-ba07-8e5b08b78f7b",
"url": "/v2/buildpacks/16e73f3c-3980-4603-ba07-8e5b08b78f7b",
"created_at": "2015-06-30T00:10:37Z",
"updated_at": null
},
"entity": {
"name": "test-binary-bp",
"position": 1,
"enabled": true,
"locked": false,
"filename": null
}
}
OK
Uploading buildpack test-binary-bp...
REQUEST: [2015-06-29T20:10:37-04:00]
PUT /v2/buildpacks/16e73f3c-3980-4603-ba07-8e5b08b78f7b/bits HTTP/1.1
Host: api.10.244.0.34.xip.io
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data;
boundary=a63345d0d8a03bcdf636aed591aa2d57acfe2e910bcc2a3835ed609c270f
User-Agent: go-cli 6.11.3-cebadc9 / darwin
[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading
RESPONSE: [2015-06-29T20:10:37-04:00]
HTTP/1.1 201 Created
Content-Length: 387
Content-Type: application/json;charset=utf-8
Date: Tue, 30 Jun 2015 00:10:37 GMT
Server: nginx
X-Cf-Requestid: dd6cff31-5d91-4730-6f46-cd6e085bd007
X-Content-Type-Options: nosniff
X-Vcap-Request-Id:
f5db441f-1293-429a-460a-74eb71cffaeb::c0a244bf-a50b-47d3-b2f1-cbab01a3d22a
{
"metadata": {
"guid": "16e73f3c-3980-4603-ba07-8e5b08b78f7b",
"url": "/v2/buildpacks/16e73f3c-3980-4603-ba07-8e5b08b78f7b",
"created_at": "2015-06-30T00:10:37Z",
"updated_at": "2015-06-30T00:10:37Z"
},
"entity": {
"name": "test-binary-bp",
"position": 1,
"enabled": true,
"locked": false,
"filename": "binary_buildpack-cached-v1.0.1.zip"
}
}
OK
✓ $ cf buildpacks
Getting buildpacks...
buildpack position enabled locked filename
test-binary-bp 1 true false
binary_buildpack-cached-v1.0.1.zip
staticfile_buildpack 2 true false
staticfile_buildpack-cached-v1.2.0.zip
java_buildpack 3 true false
java-buildpack-v3.0.zip
ruby_buildpack 4 true false
ruby_buildpack-cached-v1.4.2.zip
nodejs_buildpack 5 true false
nodejs_buildpack-cached-v1.3.4.zip
go_buildpack 6 true false
go_buildpack-cached-v1.4.0.zip
python_buildpack 7 true false
python_buildpack-cached-v1.4.0.zip
php_buildpack 8 true false
php_buildpack-cached-v3.3.0.zip
binary_buildpack 9 true false
binary_buildpack-cached-v1.0.1.zip
✓ $ cf --version
cf version 6.11.3-cebadc9-2015-05-20T18:59:33+00:00
For buildpacks, nginx handles most of the heavy lifting and then passes
modified parameters to the cc for processing. The upload processor then
uses the modified params to do the right thing...
Are you running a non-standard configuration that doesn't use nginx to
frontend cc?
toggle quoted message
Show quoted text
On Mon, Jun 29, 2015 at 3:22 PM, kyle havlovitz <kylehav(a)gmail.com> wrote: After some more digging I found that it seems to be a problem in
https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/controllers/runtime/buildpack_bits_controller.rb#L21
.
The 'params' object here is being referenced incorrectly; it contains a
key called 'buildpack' that maps to an object which has a :filename field
which contains the correct buildpack filename, but the code is trying to
reference params['buildpack_name'], which doesn't exist, so it throws an
exception. Changing that above line to say uploaded_filename
= params['buildpack'][:filename] fixed the issue for me. Could this be
caused by my CLI and the cloud controller having out of sync versions? The
api version on the CC is 2.23.0, and tI've been using the 6.11 CLI.
On Mon, Jun 29, 2015 at 9:31 AM, kyle havlovitz <kylehav(a)gmail.com> wrote:
Here's a gist of the output I get and the command I run:
https://gist.github.com/MrEnzyme/7ebd45c9c34151a52050
On Fri, Jun 26, 2015 at 10:58 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
It should work since our acceptance tests validate this on every build
we cut [1]. Are you running the operation as someone with a cc admin scope?
If you want to create a gist with the log (with secrets redacted) from
running `cf` with CF_TRACE=true, we could certainly take a look.
[1]:
https://github.com/cloudfoundry/cf-acceptance-tests/blob/cdced815f585ef4661b2182799d1d6a7119489b0/apps/app_stack_test.go#L36-L104
On Fri, Jun 26, 2015 at 2:36 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:
I'm having an issue where I can't upload any buildpack to cloudfoundry;
it says "The buildpack upload is invalid: a filename must be specified" and
the cf_trace confirms it's sending a null value for filename. The thing is,
I have specified a file name every time and get this error. I've used a few
different CLI versions and uploaded different buildpacks as both zip
files/directories, and nothing works. Is this a bug in the CLI/cloud
controller, or am I doing something wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
|
|
|
Re: CF rollback issue from v210 to v202
Hi James,
Thanks a lot , Please could you tell us what is the clean way of doing
rollback from v210 to v202.
Regards
Lingesh M
toggle quoted message
Show quoted text
On Mon, Jun 29, 2015 at 5:58 PM, James Bayer <jbayer(a)pivotal.io> wrote: when you upgrade to a newer version of cf-release, it performs database
migrations. the message is likely telling you that cf-release v202 code in
the cloud controller is not compatible with the db migrations that were
performed when upgrading to cf-release v210.
On Mon, Jun 29, 2015 at 2:53 PM, Lingesh Mouleeshwaran <
lingeshmouleeshwaran(a)gmail.com> wrote:
Hello Team ,
we are able to upgrade cf 202 to v210 in development environment , incase
of any unknown issue we may want to rollback to 202. So we are trying to
rollback from 210 to 202. But bosh not able to complete the rollback
successfully. we are getting below error from bosh.
Error :
Started updating job api_z1
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is
not running after update (00:14:53)
Error 400007: `api_z1/0' is not running after update
even we are able to ssh on api_z1 successfully. but found below issue in
cloud_controller_ng .
monit summary
The Monit daemon 5.2.4 uptime: 13m
Process 'cloud_controller_ng' Execution failed
Process 'cloud_controller_worker_local_1' not monitored
Process 'cloud_controller_worker_local_2' not monitored
Process 'nginx_cc' not monitored
Process 'metron_agent' running
Process 'check_mk' running
System 'system_6e1e4d43-f677-4dc6-ab8a-5b6152504918' running
logs from : /var/vcap/sys/log/cloud_controller_ng_ctl.err.log
[2015-06-29 21:18:55+0000] Tasks: TOP => db:migrate
[2015-06-29 21:18:55+0000] (See full trace by running task with --trace)
[2015-06-29 21:19:39+0000] ------------ STARTING cloud_controller_ng_ctl
at Mon Jun 29 21:19:36 UTC 2015 --------------
[2015-06-29 21:19:39+0000] rake aborted!
[2015-06-29 21:19:39+0000] Sequel::Migrator::Error: Applied migration
files not in file system:
20150306233007_increase_size_of_delayed_job_handler.rb,
20150311204445_add_desired_state_to_v3_apps.rb,
20150313233039_create_apps_v3_routes.rb,
20150316184259_create_service_key_table.rb,
20150318185941_add_encrypted_environment_variables_to_apps_v3.rb,
20150319150641_add_encrypted_environment_variables_to_v3_droplets.rb,
20150323170053_change_service_instance_description_to_text.rb,
20150323234355_recreate_apps_v3_routes.rb,
20150324232809_add_fk_v3_apps_packages_droplets_processes.rb,
20150325224808_add_v3_attrs_to_app_usage_events.rb,
20150327080540_add_cached_docker_image_to_droplets.rb,
20150403175058_add_index_to_droplets_droplet_hash.rb,
20150403190653_add_procfile_to_droplets.rb,
20150407213536_add_index_to_stack_id.rb,
20150421190248_add_allow_ssh_to_app.rb, 20150422000255_route_path_field.rb,
20150430214950_add_allow_ssh_to_spaces.rb,
20150501181106_rename_apps_allow_ssh_to_enable_ssh.rb,
20150514190458_fix_mysql_collations.rb,
20150515230939_add_case_insensitive_to_route_path.rb
cloud_controller_ng_ctl.err.log
Please any idea is some thing problem with rollback scripts during
rollback ??.
Regards
Lingesh M
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Document for service broker api version 2.5
Nguyen, The cause of your error is explained here: App Log Streaming - http://docs.cloudfoundry.org/services/app-log-streaming.htmlYour broker is returning syslog_drain_url in response to a bind request, but has not declared requires:syslog_drain in the catalog endpoint. Catalog: http://docs.cloudfoundry.org/services/api.html#catalog-mgmtResponse Body services.requires - A list of permissions that the user would have to give the service, if they provision it. The only permission currently supported is syslog_drain. Binding: http://docs.cloudfoundry.org/services/api.html#bindingResponse Body syslog_drain_url - A URL to which Cloud Foundry should drain logs to for the bound application. I noticed that in our description for the syslog_drain_url field, we should probably also refer to the requires field. I'll update the docs. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Mon, Jun 29, 2015 at 3:04 AM, NGUYEN Hong Chau <nguyenhongchau(a)gmail.com> wrote: Thank James and Shannon for your answer,
The support for the Arbitrary Parameters feature is actually a great
improvement for service broker. I'm really wish to test it soon.
Now when i'm implementing my service broker, the operation fails at
binding the created service instance to an application:
"FAILED
Server error, status code: 502, error code: 10001, message: The service is
attempting to stream logs from your application, but is not registered as a
logging service. Please contact the service provider."
I'll try to check the logs from brokers and controller,
Regards,
--
NGUYEN Hong Chau
On Fri, Jun 26, 2015 at 11:57 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
Hello,
A commit to increment the broker API version header went out by mistake.
We are currently backfilling docs for 2.5 (should be published very soon):
https://www.pivotaltracker.com/story/show/88824286
Broker API v2.5 represents support for the Arbitrary Parameters feature.
Cloud Controller may include a field called "parameters" in the provision,
update, and bind request bodies. Values for this field are only included if
provided by the CF API client (CLI, etc).
These changes are expected to be backwards compatible. A broker that does
not support the "parameters" field should ignore it.
Info that could help troubleshoot:
- what operation fails; create/update broker, provision, bind, etc?
- logs from the broker of the request and response
- logs from cloud controller of the request and response to the broker
- output of CLI with CF_TRACE=true
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Thu, Jun 25, 2015 at 8:26 PM, James Bayer <jbayer(a)pivotal.io> wrote:
looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html
2.5 should only have been incremental changes and should be backward
compatible with other 2.x versions.
when you say it doesn't work, do you have details of an interaction that
shows the problem?
On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <
nguyenhongchau(a)gmail.com> wrote:
Hi all,
I'm trying to implement a service broker for cf-release v210. I
implemented my service broker in cf-release v207 based on this service
broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code
doesn't work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?
Thanks in advance.
--
Nguyen Hong-Chau
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Nguyen Hong-Chau
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: Document for service broker api version 2.5
We have just published documentation for the service broker API specification v2.5, which adds support for arbitrary parameters with create, update, and bind. http://docs.cloudfoundry.org/services/api.htmlMy apologies for the confusion this must have caused. We typically ship docs at the same time as incrementing the X-Broker-Api-Version header. Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. On Mon, Jun 29, 2015 at 3:04 AM, NGUYEN Hong Chau <nguyenhongchau(a)gmail.com> wrote: Thank James and Shannon for your answer,
The support for the Arbitrary Parameters feature is actually a great
improvement for service broker. I'm really wish to test it soon.
Now when i'm implementing my service broker, the operation fails at
binding the created service instance to an application:
"FAILED
Server error, status code: 502, error code: 10001, message: The service is
attempting to stream logs from your application, but is not registered as a
logging service. Please contact the service provider."
I'll try to check the logs from brokers and controller,
Regards,
--
NGUYEN Hong Chau
On Fri, Jun 26, 2015 at 11:57 PM, Shannon Coen <scoen(a)pivotal.io> wrote:
Hello,
A commit to increment the broker API version header went out by mistake.
We are currently backfilling docs for 2.5 (should be published very soon):
https://www.pivotaltracker.com/story/show/88824286
Broker API v2.5 represents support for the Arbitrary Parameters feature.
Cloud Controller may include a field called "parameters" in the provision,
update, and bind request bodies. Values for this field are only included if
provided by the CF API client (CLI, etc).
These changes are expected to be backwards compatible. A broker that does
not support the "parameters" field should ignore it.
Info that could help troubleshoot:
- what operation fails; create/update broker, provision, bind, etc?
- logs from the broker of the request and response
- logs from cloud controller of the request and response to the broker
- output of CLI with CF_TRACE=true
Thank you,
Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.
On Thu, Jun 25, 2015 at 8:26 PM, James Bayer <jbayer(a)pivotal.io> wrote:
looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html
2.5 should only have been incremental changes and should be backward
compatible with other 2.x versions.
when you say it doesn't work, do you have details of an interaction that
shows the problem?
On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <
nguyenhongchau(a)gmail.com> wrote:
Hi all,
I'm trying to implement a service broker for cf-release v210. I
implemented my service broker in cf-release v207 based on this service
broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code
doesn't work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?
Thanks in advance.
--
Nguyen Hong-Chau
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Nguyen Hong-Chau
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: CF rollback issue from v210 to v202
when you upgrade to a newer version of cf-release, it performs database migrations. the message is likely telling you that cf-release v202 code in the cloud controller is not compatible with the db migrations that were performed when upgrading to cf-release v210. On Mon, Jun 29, 2015 at 2:53 PM, Lingesh Mouleeshwaran < lingeshmouleeshwaran(a)gmail.com> wrote: Hello Team ,
we are able to upgrade cf 202 to v210 in development environment , incase
of any unknown issue we may want to rollback to 202. So we are trying to
rollback from 210 to 202. But bosh not able to complete the rollback
successfully. we are getting below error from bosh.
Error :
Started updating job api_z1
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is
not running after update (00:14:53)
Error 400007: `api_z1/0' is not running after update
even we are able to ssh on api_z1 successfully. but found below issue in
cloud_controller_ng .
monit summary
The Monit daemon 5.2.4 uptime: 13m
Process 'cloud_controller_ng' Execution failed
Process 'cloud_controller_worker_local_1' not monitored
Process 'cloud_controller_worker_local_2' not monitored
Process 'nginx_cc' not monitored
Process 'metron_agent' running
Process 'check_mk' running
System 'system_6e1e4d43-f677-4dc6-ab8a-5b6152504918' running
logs from : /var/vcap/sys/log/cloud_controller_ng_ctl.err.log
[2015-06-29 21:18:55+0000] Tasks: TOP => db:migrate
[2015-06-29 21:18:55+0000] (See full trace by running task with --trace)
[2015-06-29 21:19:39+0000] ------------ STARTING cloud_controller_ng_ctl
at Mon Jun 29 21:19:36 UTC 2015 --------------
[2015-06-29 21:19:39+0000] rake aborted!
[2015-06-29 21:19:39+0000] Sequel::Migrator::Error: Applied migration
files not in file system:
20150306233007_increase_size_of_delayed_job_handler.rb,
20150311204445_add_desired_state_to_v3_apps.rb,
20150313233039_create_apps_v3_routes.rb,
20150316184259_create_service_key_table.rb,
20150318185941_add_encrypted_environment_variables_to_apps_v3.rb,
20150319150641_add_encrypted_environment_variables_to_v3_droplets.rb,
20150323170053_change_service_instance_description_to_text.rb,
20150323234355_recreate_apps_v3_routes.rb,
20150324232809_add_fk_v3_apps_packages_droplets_processes.rb,
20150325224808_add_v3_attrs_to_app_usage_events.rb,
20150327080540_add_cached_docker_image_to_droplets.rb,
20150403175058_add_index_to_droplets_droplet_hash.rb,
20150403190653_add_procfile_to_droplets.rb,
20150407213536_add_index_to_stack_id.rb,
20150421190248_add_allow_ssh_to_app.rb, 20150422000255_route_path_field.rb,
20150430214950_add_allow_ssh_to_spaces.rb,
20150501181106_rename_apps_allow_ssh_to_enable_ssh.rb,
20150514190458_fix_mysql_collations.rb,
20150515230939_add_case_insensitive_to_route_path.rb
cloud_controller_ng_ctl.err.log
Please any idea is some thing problem with rollback scripts during
rollback ??.
Regards
Lingesh M
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
-- Thank you, James Bayer
|
|
|
CF rollback issue from v210 to v202
Hello Team ,
we are able to upgrade cf 202 to v210 in development environment , incase
of any unknown issue we may want to rollback to 202. So we are trying to
rollback from 210 to 202. But bosh not able to complete the rollback
successfully. we are getting below error from bosh.
Error :
Started updating job api_z1
Started updating job api_z1 > api_z1/0 (canary). Failed: `api_z1/0' is
not running after update (00:14:53)
Error 400007: `api_z1/0' is not running after update
even we are able to ssh on api_z1 successfully. but found below issue in
cloud_controller_ng .
monit summary
The Monit daemon 5.2.4 uptime: 13m
Process 'cloud_controller_ng' Execution failed
Process 'cloud_controller_worker_local_1' not monitored
Process 'cloud_controller_worker_local_2' not monitored
Process 'nginx_cc' not monitored
Process 'metron_agent' running
Process 'check_mk' running
System 'system_6e1e4d43-f677-4dc6-ab8a-5b6152504918' running
logs from : /var/vcap/sys/log/cloud_controller_ng_ctl.err.log
[2015-06-29 21:18:55+0000] Tasks: TOP => db:migrate
[2015-06-29 21:18:55+0000] (See full trace by running task with --trace)
[2015-06-29 21:19:39+0000] ------------ STARTING cloud_controller_ng_ctl at
Mon Jun 29 21:19:36 UTC 2015 --------------
[2015-06-29 21:19:39+0000] rake aborted!
[2015-06-29 21:19:39+0000] Sequel::Migrator::Error: Applied migration files
not in file system: 20150306233007_increase_size_of_delayed_job_handler.rb,
20150311204445_add_desired_state_to_v3_apps.rb,
20150313233039_create_apps_v3_routes.rb,
20150316184259_create_service_key_table.rb,
20150318185941_add_encrypted_environment_variables_to_apps_v3.rb,
20150319150641_add_encrypted_environment_variables_to_v3_droplets.rb,
20150323170053_change_service_instance_description_to_text.rb,
20150323234355_recreate_apps_v3_routes.rb,
20150324232809_add_fk_v3_apps_packages_droplets_processes.rb,
20150325224808_add_v3_attrs_to_app_usage_events.rb,
20150327080540_add_cached_docker_image_to_droplets.rb,
20150403175058_add_index_to_droplets_droplet_hash.rb,
20150403190653_add_procfile_to_droplets.rb,
20150407213536_add_index_to_stack_id.rb,
20150421190248_add_allow_ssh_to_app.rb, 20150422000255_route_path_field.rb,
20150430214950_add_allow_ssh_to_spaces.rb,
20150501181106_rename_apps_allow_ssh_to_enable_ssh.rb,
20150514190458_fix_mysql_collations.rb,
20150515230939_add_case_insensitive_to_route_path.rb
cloud_controller_ng_ctl.err.log
Please any idea is some thing problem with rollback scripts during rollback
??.
Regards
Lingesh M
|
|
|
Re: private vs public visibility of apps
toggle quoted message
Show quoted text
On Mon, Jun 29, 2015 at 2:23 PM, Josh Ghiloni <jghiloni(a)ecsteam.com> wrote: I'm sure there's an easier way to do it, but you could always map a DNS
domain to your space that does not have public visibility, then deploy your
apps to that domain.
*Josh *Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ECSTeam.com <rgarrett(a)ECSTeam.com>
*ECS Team *
*Technology Solutions Delivered*
ECSTeam.com <http://www.ecsteam.com/> <http://www.ecsteam.com/>
------------------------------
*From:* cf-dev-bounces(a)lists.cloudfoundry.org <
cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of Matthias Ender <
Matthias.Ender(a)sas.com>
*Sent:* Monday, June 29, 2015 2:46 PM
*To:* cf-dev(a)lists.cloudfoundry.org
*Subject:* [cf-dev] private vs public visibility of apps
We have a cf app that need not have public visibility.
It’s like a service, but it’s a stateless app, so making it a droplet is
convenient.
It only needs to be visible to the other apps.
How can I hide the endpoint from the outside world?
I can remove the route, but then the other apps can’t see it either.
How does one handle that in cf?
thanks,
Matthias
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
|
|
|
Re: private vs public visibility of apps
I'm sure there's an easier way to do it, but you could always map a DNS domain to your space that does not have public visibility, then deploy your apps to that domain. Josh Ghiloni Senior Consultant 303.932.2202 o | 303.590.5427 m | 303.565.2794 f jghiloni(a)ECSTeam.com<mailto:rgarrett(a)ECSTeam.com> ECS Team Technology Solutions Delivered ECSTeam.com< http://www.ecsteam.com/> < http://www.ecsteam.com/> ________________________________ From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of Matthias Ender <Matthias.Ender(a)sas.com> Sent: Monday, June 29, 2015 2:46 PM To: cf-dev(a)lists.cloudfoundry.org Subject: [cf-dev] private vs public visibility of apps We have a cf app that need not have public visibility. It's like a service, but it's a stateless app, so making it a droplet is convenient. It only needs to be visible to the other apps. How can I hide the endpoint from the outside world? I can remove the route, but then the other apps can't see it either. How does one handle that in cf? thanks, Matthias
|
|
|
private vs public visibility of apps
Matthias Ender <Matthias.Ender@...>
We have a cf app that need not have public visibility.
It's like a service, but it's a stateless app, so making it a droplet is convenient.
It only needs to be visible to the other apps.
How can I hide the endpoint from the outside world?
I can remove the route, but then the other apps can't see it either.
How does one handle that in cf?
thanks,
Matthias
|
|
|
Re: Can't create/update buildpacks, "a filename must be specified"
kyle havlovitz <kylehav@...>
After some more digging I found that it seems to be a problem in https://github.com/cloudfoundry/cloud_controller_ng/blob/master/app/controllers/runtime/buildpack_bits_controller.rb#L21. The 'params' object here is being referenced incorrectly; it contains a key called 'buildpack' that maps to an object which has a :filename field which contains the correct buildpack filename, but the code is trying to reference params['buildpack_name'], which doesn't exist, so it throws an exception. Changing that above line to say uploaded_filename = params['buildpack'][:filename] fixed the issue for me. Could this be caused by my CLI and the cloud controller having out of sync versions? The api version on the CC is 2.23.0, and tI've been using the 6.11 CLI.
On Mon, Jun 29, 2015 at 9:31 AM, kyle havlovitz <kylehav(a)gmail.com> wrote: Here's a gist of the output I get and the command I run:
https://gist.github.com/MrEnzyme/7ebd45c9c34151a52050
On Fri, Jun 26, 2015 at 10:58 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
It should work since our acceptance tests validate this on every build we
cut [1]. Are you running the operation as someone with a cc admin scope?
If you want to create a gist with the log (with secrets redacted) from
running `cf` with CF_TRACE=true, we could certainly take a look.
[1]:
https://github.com/cloudfoundry/cf-acceptance-tests/blob/cdced815f585ef4661b2182799d1d6a7119489b0/apps/app_stack_test.go#L36-L104
On Fri, Jun 26, 2015 at 2:36 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:
I'm having an issue where I can't upload any buildpack to cloudfoundry;
it says "The buildpack upload is invalid: a filename must be specified" and
the cf_trace confirms it's sending a null value for filename. The thing is,
I have specified a file name every time and get this error. I've used a few
different CLI versions and uploaded different buildpacks as both zip
files/directories, and nothing works. Is this a bug in the CLI/cloud
controller, or am I doing something wrong?
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: App deployment hangs in legacy CF installation
Hi James
Thanks for the info. I and my team greatly appreciate your time here. I
believe we are running on v153 (or close to that), which is very old.
I will have a look at those components more closely. A symptom we observe
is sometimes an app deployed successfully, the app would crash in a few
minutes even without activity.
What we see is socket closed on read error (which indicates IMO the
container was killed and the logger could not contact it).
John
toggle quoted message
Show quoted text
On Mon, Jun 29, 2015 at 1:35 PM, James Bayer <jbayer(a)pivotal.io> wrote: once you get to this line where you make the app started [1], then the
next step is that the cloud controller should be sending a NATS message
targeted at a particular DEA selected to run the app.
so you could monitor:
* NATS to see if you see the CC sending the NATS message
* the DEA logs to see if it receives the message
* the DEA to logs see if it is able to react to the message once it
receives it
we have had issues in the past where NATS issues on client/server
communication were addressed with restarting clients and servers, but it's
been quite awhile. letting us know which cf-release you are using could
help.
[1]
https://gist.github.com/yeukhon/666fa1936ef3473c6de6#file-gistfile1-txt-L534
On Mon, Jun 29, 2015 at 7:20 AM, John Wong <gokoproject(a)gmail.com> wrote:
Hi.
We are running on an extremely old version of CF (we are in the process
of building one based on the latest), so I know there is very little the
community may be able to help.
But regardless... let me give it a try.
In my debug session, I tried to deploy a hello world app, and deployment
stopped with "STARTED" and eventually timeout.
The full log:
https://gist.githubusercontent.com/yeukhon/666fa1936ef3473c6de6/raw/1f662b86e806ab1fff230f5558f4942d9785c584/gistfile1.txt
I can easily reproduce this when I did two concurrent push. Sometimes
they go through, sometimes they don't.
We have looked at every log in CF and we don't have any lead. I did bosh
restart JOB hoping it was caused by a slow process, but that did not help.
I found ntp was not installed on some of the components (we installed ntp
on all of the DEAs), and i found clock was not synced so I synced the
clocked, and still no help.
Any idea where I should look at? I thought about our EC2 instance health
but all of them seem to be healthy. I am considering relaunching (bosh
recreate) one component at a time.
The one thing I did notice is I am constantly deploying to a couple DEAs.
I will look into them but I am not sure...
Any ideas will be appreciated. Thanks.
John
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: App deployment hangs in legacy CF installation
once you get to this line where you make the app started [1], then the next step is that the cloud controller should be sending a NATS message targeted at a particular DEA selected to run the app. so you could monitor: * NATS to see if you see the CC sending the NATS message * the DEA logs to see if it receives the message * the DEA to logs see if it is able to react to the message once it receives it we have had issues in the past where NATS issues on client/server communication were addressed with restarting clients and servers, but it's been quite awhile. letting us know which cf-release you are using could help. [1] https://gist.github.com/yeukhon/666fa1936ef3473c6de6#file-gistfile1-txt-L534
On Mon, Jun 29, 2015 at 7:20 AM, John Wong <gokoproject(a)gmail.com> wrote: Hi.
We are running on an extremely old version of CF (we are in the process of
building one based on the latest), so I know there is very little the
community may be able to help.
But regardless... let me give it a try.
In my debug session, I tried to deploy a hello world app, and deployment
stopped with "STARTED" and eventually timeout.
The full log:
https://gist.githubusercontent.com/yeukhon/666fa1936ef3473c6de6/raw/1f662b86e806ab1fff230f5558f4942d9785c584/gistfile1.txt
I can easily reproduce this when I did two concurrent push. Sometimes they
go through, sometimes they don't.
We have looked at every log in CF and we don't have any lead. I did bosh
restart JOB hoping it was caused by a slow process, but that did not help.
I found ntp was not installed on some of the components (we installed ntp
on all of the DEAs), and i found clock was not synced so I synced the
clocked, and still no help.
Any idea where I should look at? I thought about our EC2 instance health
but all of them seem to be healthy. I am considering relaunching (bosh
recreate) one component at a time.
The one thing I did notice is I am constantly deploying to a couple DEAs.
I will look into them but I am not sure...
Any ideas will be appreciated. Thanks.
John
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
|
|
|
Re: SSH access to CF app instances on Diego
after executing a command, concluding an interactive session, or copying a file into an instance, that instance will be restarted. How does it monitor the behavior? Is there a list of commands whitelisted? I am curious because I am trying to find out what the whitelist contain. Also is it at the end of the bosh ssh APP_NAME session? What if two users are there simultaneously? Thanks. On Mon, Jun 29, 2015 at 5:49 AM, Dieu Cao <dcao(a)pivotal.io> wrote: I think with the CLI we could add clarifying messaging when using ssh what
the current policy around recycling is.
Eric, what do you think about calling it the "recycling" policy, enabled
by default? =D
-Dieu
On Sat, Jun 27, 2015 at 3:42 AM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
Depends on your role and where your app is in the deployment pipeline.
Most of the scenarios I envisioned were for the tail end of development
where you need to poke around to debug and figure out those last few
problems.
For example, Ryan Morgan was saying that the Cloud Foundry plugin for
eclipse is going to be using the ssh support in diego to enable debug of
application instances in the context of a buildpack deployed app. This is
aligned with other requirements I've heard from people working on dev tools.
As apps reach production, I would hope that interactive ssh is disabled
entirely on the prod space leaving only scp in source mode as an option
(something the proxy can do).
Between dev and prod, there's a spectrum, but in general, I either expect
access to be enabled or disabled - not enabled with a suicidal tendency.
On Thu, Jun 25, 2015 at 10:53 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:
matt,
could you elaborate a bit on what you believe ssh access to instances is
for?
b
On Thu, Jun 25, 2015 at 9:29 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:
My concern is the default behavior.
When I first prototyped this support in February, I never expected that
merely accessing a container would cause it to be terminated. As we can see
from Jan's response, it's completely unexpected; many others have the same
reaction.
I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.
I honestly believe that if we were talking about applying this behavior
to `bosh ssh` and `bosh scp`, few would even consider running in a 'kill on
taint mode' because of how useful it is. We should learn from that.
If this behavior becomes the default, I think our platform will be seen
as moving from opinionated to parochial. That would be unfortunate.
On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:
you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.
On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com>
wrote:
On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that instance will
be restarted. What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?
Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Matthew Sykes
matthew.sykes(a)gmail.com
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Re: When will diego release?
looking at the public tracker for diego, you can track as the team approaches this important release marker [1] named "Diego can replace DEAs". pivotal is using diego in our hosted production envs for a portion of our traffic today. we have a projected plan to switch over completely in the mid/late august time frame. [1] https://www.pivotaltracker.com/story/show/76376202
On Sun, Jun 28, 2015 at 8:39 PM, libnux <libnux.me(a)gmail.com> wrote: Hi,
We're going to use diego in production. Could you please give the date of
the first formal release?
Thanks.
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
|
|
|
Re: Feedback: A slightly different perspective on route services
Mike Youngstrom <youngm@...>
Yes, though in your "https only" example the route service broker would be
the one to interpret how to implement the attribute or service bound to the
route and choose to either provide a proxy or configure other outside
resources accordingly. An "https only" service broker might choose to
implement its functionality with a proxy that looks for the X-Forwarded_For
header. In this case CF knows how to handle that proxy url returned just
like CF knows how to handle a syslog drain url returned by something like a
splunk service broker.
Re-configuring the frontend load balancer might be the way some other
service broker might choose to implement binding to a route.
I think a proxy is only one way someone might choose to implement a route
service. So, lets look at a proxy route service as simply one type of
route service. Making services bound to routes more flexible.
Mike
toggle quoted message
Show quoted text
On Mon, Jun 29, 2015 at 4:02 AM, Dieu Cao <dcao(a)pivotal.io> wrote: Hi Mike,
I think I understand your use case.
Currently route services are specced out such that they must, at minimum,
function like a proxy.
I think you're proposing that a route service could be a service that is
not a proxy.
I think what would be needed is a way to specify things, like https only
for example, as a route service, such that a router, like the gorouter, or
tcp router, could interpret that attribute on the route and apply that
behavior.
That sound right?
-Dieu
On Sat, Jun 27, 2015 at 2:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:
i think i understand what you mean now. shannon has thought through those
concepts and relationships and the options for how to express them. i'll
let him comment on his current thinking. i got hung up on this example not
being complete and assumed you mean binding to an app:
cf bind/unbind-route-service
more explicitly, i believe you're advocating for an experience like:
cf bind-route-service ROUTE SERVICE_INSTANCE
cf unbind-route-service ROUTE SERVICE_INSTANCE
where ROUTE today is typically expressed with the compound "DOMAIN -n
HOSTNAME" rather a named alias.
On Fri, Jun 26, 2015 at 7:23 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:
Let me clarify. I'm still 100% on board with binding a service to a
route. What I'm proposing with my different perspective is to decouple the
idea of a Route service being a proxy and think of a service bound to a
route as a generic way to apply enhanced functionality to a route (not
necessarily through a proxy) and make applying a proxy to a route a
standard extension to a route service similar in concept to how a service
meant to be bound to an app can be enhanced to provide a log drain.
Does that make sense?
Mike
On Fri, Jun 26, 2015 at 1:36 AM, James Bayer <jbayer(a)pivotal.io> wrote:
we explored the ux of app to service binding in detail, but it is
problematic.
apps will soon support multiple routes on different ports.
e.g. imagine an app with 3 ports:
web traffic goes to container port 8080 on web.example.com
admin traffic goes to container port 8888 on admin.example.com
jmx goes to 9000 on jmx.example.com
which of the 3 routes should the route service bound to the app be
associated with?
a route can be mapped to multiple apps, what happens when some apps
mapped to a route have a route service bound and others don't?
shannon can probably explain more of the problem areas that we
discussed, i need to get to bed :)
On Thu, Jun 25, 2015 at 11:55 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:
This thread [0] on Route services has got me thinking. I'd like to
propose a slightly different perspective on the route services concept.
A typical service today, lets call them "App Services" at its most
base function exists to apply some functionality to an application.
Typically that functionality comes in the form of credentials supplied to
an application. But not always. For example, a Log Drain App Service
applies log drain functionality to an app. My organization has other
services that apply other functionality to an app not necessarily in the
form of credentials.
So, with that perspective what should a "Route Service" be? I think
at its basest form a Route Service should simply be a way to applying
functionality to a Route. (note I said nothing about proxies).
Just like a log drain app service is a type of App Service. I think a
Proxy Route Service could be viewed as a type of Route Service. Why is
this distinction important? I think it keeps the vision of a route service
more simple, pure, and less implementation specific.
I think with this perspective route services become much simpler and
more powerful. You support binding one or more route services to a route
just like today you can bind one or more app services to an app. However,
if the service identifies itself as a Proxy Route Service (just like a
service can identify itself as a log drain service) then the Cloud
Controller simply fails the bind because today we only allow one proxy
route services to be bound to a route at a time. The UX becomes simply:
cf bind/unbind-route-service
We leave the problem of ordering multiple Proxy Route Services as a
future problem. Of which I think user provided ordering is only one
possible solution. I believe other more natural and simple solutions will
present themselves over time.
Thoughts?
Mike
[0]
http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000535.html
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,
James Bayer
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
App deployment hangs in legacy CF installation
Hi. We are running on an extremely old version of CF (we are in the process of building one based on the latest), so I know there is very little the community may be able to help. But regardless... let me give it a try. In my debug session, I tried to deploy a hello world app, and deployment stopped with "STARTED" and eventually timeout. The full log: https://gist.githubusercontent.com/yeukhon/666fa1936ef3473c6de6/raw/1f662b86e806ab1fff230f5558f4942d9785c584/gistfile1.txtI can easily reproduce this when I did two concurrent push. Sometimes they go through, sometimes they don't. We have looked at every log in CF and we don't have any lead. I did bosh restart JOB hoping it was caused by a slow process, but that did not help. I found ntp was not installed on some of the components (we installed ntp on all of the DEAs), and i found clock was not synced so I synced the clocked, and still no help. Any idea where I should look at? I thought about our EC2 instance health but all of them seem to be healthy. I am considering relaunching (bosh recreate) one component at a time. The one thing I did notice is I am constantly deploying to a couple DEAs. I will look into them but I am not sure... Any ideas will be appreciated. Thanks. John
|
|
|
