I know it's recommended, but uploading buildpacks seems to just be plain
broken without it (though I fixed it by changing 1 line of code in the
cloud controller). The question is, is this supposed to work or is this
something broken that I should make a PR for?

On Tue, Jun 30, 2015 at 5:56 PM, CF Runtime <cfruntime(a)gmail.com> wrote:

Hi Kyle,

We highly recommend using Nginx as a proxy for uploads and downloads
to/from the cloud controller. Without it all long-running data transfers to
the CC will block that instance of the cloud controller.

It's possible, but may have unintended and unsupported side-effects.

Best,
Zachary Auerbach, CF Runtime Team.

On Tue, Jun 30, 2015 at 10:45 AM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

The thing is, I got it to work with use_nginx set to false just by
modifying one line of code in buildpack_bits_controller.rb. Couldn't the
code just be changed to support this?

On Tue, Jun 30, 2015 at 1:36 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Yes, nginx is required.

-Dieu

On Tue, Jun 30, 2015 at 3:32 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Yes, I have nginx disabled, would that cause problems uploading a
buildpack like this?

On Mon, Jun 29, 2015 at 9:18 PM, Matthew Sykes <
matthew.sykes(a)gmail.com> wrote:

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?

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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
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

Hi Kyle,

We highly recommend using Nginx as a proxy for uploads and downloads
to/from the cloud controller. Without it all long-running data transfers to
the CC will block that instance of the cloud controller.

It's possible, but may have unintended and unsupported side-effects.

Best,
Zachary Auerbach, CF Runtime Team.

On Tue, Jun 30, 2015 at 10:45 AM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

The thing is, I got it to work with use_nginx set to false just by
modifying one line of code in buildpack_bits_controller.rb. Couldn't the
code just be changed to support this?

On Tue, Jun 30, 2015 at 1:36 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Yes, nginx is required.

-Dieu

On Tue, Jun 30, 2015 at 3:32 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Yes, I have nginx disabled, would that cause problems uploading a
buildpack like this?

On Mon, Jun 29, 2015 at 9:18 PM, Matthew Sykes <matthew.sykes(a)gmail.com

wrote:

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?

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

_______________________________________________
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

_______________________________________________
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

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

The thing is, I got it to work with use_nginx set to false just by
modifying one line of code in buildpack_bits_controller.rb. Couldn't the
code just be changed to support this?

On Tue, Jun 30, 2015 at 1:36 PM, Dieu Cao <dcao(a)pivotal.io> wrote:

Yes, nginx is required.

-Dieu

On Tue, Jun 30, 2015 at 3:32 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:

Yes, I have nginx disabled, would that cause problems uploading a
buildpack like this?

On Mon, Jun 29, 2015 at 9:18 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

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?

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

_______________________________________________
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

_______________________________________________
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

On Tue, Jun 30, 2015 at 8:26 AM, James Bayer <jbayer(a)pivotal.io> wrote:

you can track that with this release marker:
https://www.pivotaltracker.com/story/show/97428076

I've been wondering about this before: how do you actually "track"
anything with such a marker? Even if I create an account on Pivotal
tracker, all I get to see is this:


https://www.evernote.com/shard/s1/sh/11fc0380-dfe0-4ce7-9399-6c1c0f4a59ef/ecaacac2cb6961d6

So how do I see what kind of progress is being made/how much is left
to do to reach this marker?

Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Yes, nginx is required.

-Dieu

On Tue, Jun 30, 2015 at 3:32 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:

Yes, I have nginx disabled, would that cause problems uploading a
buildpack like this?

On Mon, Jun 29, 2015 at 9:18 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

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?

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

_______________________________________________
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

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

Yes, I have nginx disabled, would that cause problems uploading a
buildpack like this?

On Mon, Jun 29, 2015 at 9:18 PM, Matthew Sykes <matthew.sykes(a)gmail.com>
wrote:

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?

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

_______________________________________________
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

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

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

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

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

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