|
Hi Kyle,
The fundamental issue with not using Nginx is that all uploads/downloads
block the cloud controller instance. A long blocking request to the CC can
be a serious issue in any CF environment. As such, all instances of the CC
should be deployed with Nginx enabled and activated.
Best,
Zachary Auerbach, CF Runtime Team.
toggle quoted message
Show quoted text
On Wed, Jul 1, 2015 at 12:09 PM, kyle havlovitz <kylehav(a)gmail.com> wrote: What will be lost by not having nginx? I've had it disabled and haven't
seen other problems before this.
On Tue, Jun 30, 2015 at 7:17 PM, CF Runtime <cfruntime(a)gmail.com> wrote:
Hi Kyle,
This component is specifically designed to work with Nginx. Despite the
fact that you can successfully upload a buildpack by making a small change
with Nginx disabled there are many other areas where not having Nginx will
severely cripple the functionality of the Cloud Controller.
Why are you trying to deploy a CC without Nginx?
Zachary Auerbach, CF Runtime Team.
On Tue, Jun 30, 2015 at 3:21 PM, kyle havlovitz <kylehav(a)gmail.com>
wrote:
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
_______________________________________________
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
|
|
|
kyle havlovitz <kylehav@...>
What will be lost by not having nginx? I've had it disabled and haven't
seen other problems before this.
toggle quoted message
Show quoted text
On Tue, Jun 30, 2015 at 7:17 PM, CF Runtime <cfruntime(a)gmail.com> wrote: Hi Kyle,
This component is specifically designed to work with Nginx. Despite the
fact that you can successfully upload a buildpack by making a small change
with Nginx disabled there are many other areas where not having Nginx will
severely cripple the functionality of the Cloud Controller.
Why are you trying to deploy a CC without Nginx?
Zachary Auerbach, CF Runtime Team.
On Tue, Jun 30, 2015 at 3:21 PM, kyle havlovitz <kylehav(a)gmail.com> wrote:
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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
|
|
|
Hi Kyle,
This component is specifically designed to work with Nginx. Despite the
fact that you can successfully upload a buildpack by making a small change
with Nginx disabled there are many other areas where not having Nginx will
severely cripple the functionality of the Cloud Controller.
Why are you trying to deploy a CC without Nginx?
Zachary Auerbach, CF Runtime Team.
toggle quoted message
Show quoted text
On Tue, Jun 30, 2015 at 3:21 PM, kyle havlovitz <kylehav(a)gmail.com> wrote: 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
|
|
|
kyle havlovitz <kylehav@...>
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?
toggle quoted message
Show quoted text
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
|
|
|
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.
toggle quoted message
Show quoted text
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
|
|
|
kyle havlovitz <kylehav@...>
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?
toggle quoted message
Show quoted text
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
|
|
|
Yes, nginx is required.
-Dieu
toggle quoted message
Show quoted text
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
|
|
|
kyle havlovitz <kylehav@...>
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
|
|
|
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
|
|
|
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
|
|
|
kyle havlovitz <kylehav@...>
Here's a gist of the output I get and the command I run: https://gist.github.com/MrEnzyme/7ebd45c9c34151a52050On 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
|
|
|
Matthew Sykes <matthew.sykes@...>
toggle quoted message
Show quoted text
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
|
|
|
kyle havlovitz <kylehav@...>
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?
|
|
|
