Date   

Re: Diego and Maven support

Daniel Mikusa
 

Krzysztof,

Thanks for the follow up. I pushed a test app and I'm seeing the same "503
Service Unavailable" from Maven. Is that what you're seeing?

Dan

On Sun, Oct 25, 2015 at 4:32 PM, Krzysztof Wilk <chris.m.wilk(a)gmail.com>
wrote:

Dan,

It seems to me that there is more than one cause of this problem.

I have done the following:
1. upgraded cf CLI from 6.12 to 6.13
2.cf set-health-check MY_APP_NAME none
3. set <healthCheckTimeout>180</healthCheckTimeout> (pom.xml)
4. removed env variables in order to allow Maven to set them again

Still no luck.

However, I have read that there is intensive development of Maven client
plugin 2.x happening now. I will give it a try as soon as first release is
available.

Best,
Krzysztof


Re: mono apps are failed to start in CF

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

Do you have some hello world example to tests in local?
A hello world example?

Juan Antonio


Re: CF-RELEASE v202 UPLOAD ERROR

Parthiban Annadurai <senjiparthi@...>
 

Amit, I already tried that troubleshooting options, always same error. As
you mentioned, I have attached the BOSH VMs and BOSH CCK REPORT. Thanks.

On 26 October 2015 at 09:23, Amit Gupta <agupta(a)pivotal.io> wrote:

Try some of these diagnostics:
https://docs.cloudfoundry.org/running/troubleshooting.html#bound-timeout
Also, run "bosh vms --details" and "bosh cck --report" and share the
outputs.

On Mon, Oct 26, 2015 at 12:16 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Actually, sorry for the previous mails. Since, I have started with CF
v202 release and it thrown some error so am switched to CF v210. But, again
because of some rollback issues we went back with CF v202 itself.
Currently, bosh deploy throws the following, I have attached the Debug Logs
too. Thanks.

Director task 310
Started unknown
Started unknown > Binding deployment. Done (00:00:00)

Started preparing deployment
Started preparing deployment > Binding releases. Done (00:00:00)
Started preparing deployment > Binding existing deployment. Done
(00:00:01)
Started preparing deployment > Binding resource pools. Done (00:00:00)
Started preparing deployment > Binding stemcells. Done (00:00:00)
Started preparing deployment > Binding templates. Done (00:00:00)
Started preparing deployment > Binding properties. Done (00:00:00)
Started preparing deployment > Binding unallocated VMs. Done (00:00:00)
Started preparing deployment > Binding instance networks. Done
(00:00:00)

Started preparing package compilation > Finding packages to compile.
Done (00:00:00)

Started preparing dns > Binding DNS. Done (00:00:00)

Started creating bound missing vms
Started creating bound missing vms > medium_z1/0
Started creating bound missing vms > medium_z1/1
Started creating bound missing vms > router_z2/0. Done (00:01:09)
Failed creating bound missing vms > medium_z1/1: Timed out sending
`get_task' to f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds
(00:04:03)
Done creating bound missing vms > medium_z1/0 (00:05:14)
Failed creating bound missing vms (00:05:14)

Error 450002: Timed out sending `get_task' to
f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds

On 24 October 2015 at 06:40, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.

On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote:

Regenerate your manifest.

On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.

On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Parthiban,

Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.

On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

I have created the manifest file using SPIFF tool. Any issues with
that?

On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:

How did you create your manifest in the first place?

On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

After trying the suggestions, now its throws the following error,

Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)

Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')

Could anyone on this??

On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:

Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.

On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Yaa sure Amit. I have attached both the files with this mail.
Could you please? Thanks.



On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io>
wrote:

Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.

On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io
wrote:
sometimes a message like that is due to networking issues.
does the bosh director and the VM it is creating have an available network
path to reach each other? sometimes ssh'ing in to the VM that is identified
can yield more debug clues.

On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?

Regards

Parthiban A



On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:

Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.

Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties

On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:

hi parthiban

It seems you are running out of space in your vm in which
you are compiling . try to increase the size of memory in your compilation
vm .

regards
Bharath



On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,

Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)

Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe

Could Anyone on this issue?

Regards

Parthiban A

On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:

Hi partiban

can u do a checksum of the tar file .


it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*

example:

*sha1sum {file}*

regards
Bharath

On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:

You actually do not need to download it. if you just
run --

`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>

The director will pull in the release directly from
bosh.io.

--
Thank you,

James Bayer


Re: PHP extension 'gettext' doesn't work?

Daniel Mikusa
 

Mike,

That sounds good. Happy to retest after that work has been done and
confirm it resolves the issue here.

Dan

On Mon, Oct 26, 2015 at 9:11 AM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:

I'm actually open to adding commonly-used locales to the rootfs; though
that wouldn't help anyone until they're able to upgrade.

I'd like to propose that we install the debian package `locales`, which
looks like it includes support for 311 locales and 232 charmaps. It's only
about 10MB installed (according to
http://packages.ubuntu.com/trusty/locales).

Objections? Tracker story is here:
https://www.pivotaltracker.com/story/show/106641954




On Fri, Oct 23, 2015 at 8:44 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

OK, so really sorry this took me so long to investigate, but I think I've
found the issue. Ubuntu has these "language packs" and in order for
gettext to work the system has to have that language pack installed.

https://help.ubuntu.com/community/Locale

You can see what language packs are installed on your system by running
`locale -a`. I was testing this on an Ubuntu docker image and the only way
I could make it work was to install the language pack. As soon as I did
that and restarted Apache HTTPD, I started to get my translations.

Running `locale -a` on the `cflinuxfs2` docker image shows that only
these language packs are installed.

```
$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
```

When I setup a test app and run it on CF, I get the same results. Only
`en_US.utf8` works.

Unfortunately, I'm not sure how you could go about installing more
language packs into the stack for CF. It seems that you have to install
them via `apt-get` and that simply won't work, since there's no root access
in the container. If anyone has any ideas about how to install more
language packs, let me know.

My only suggestion would be to use the intl extension instead of
gettext. I believe it offers similar functionality, although it's not
something I've done myself.

Hope that helps!

Dan


On Fri, Oct 9, 2015 at 4:47 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com>
wrote:

Hi.
Thanks for your confirmation.
I'm glad that it seems like my intention is being conveyed.
(I'm sorry about my poor English...)

I'm looking forward to hearing a second look from you.


Thanks.

Hiroaki UKAJI



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984p2178.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Disable HTTP transport

Juan Antonio Breña Moral <bren at juanantonio.info...>
 

You have an example here with node:

https://github.com/jabrena/CloudFoundryLab/blob/master/Node_HelloWorld_ssl2/index.js

var ssl = false;
if(req.headers['x-forwarded-proto'] === "https"){
ssl = true;
}

Juan Antonio


Re: PHP extension 'gettext' doesn't work?

Mike Dalessio
 

I'm actually open to adding commonly-used locales to the rootfs; though
that wouldn't help anyone until they're able to upgrade.

I'd like to propose that we install the debian package `locales`, which
looks like it includes support for 311 locales and 232 charmaps. It's only
about 10MB installed (according to http://packages.ubuntu.com/trusty/locales
).

Objections? Tracker story is here:
https://www.pivotaltracker.com/story/show/106641954

On Fri, Oct 23, 2015 at 8:44 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

OK, so really sorry this took me so long to investigate, but I think I've
found the issue. Ubuntu has these "language packs" and in order for
gettext to work the system has to have that language pack installed.

https://help.ubuntu.com/community/Locale

You can see what language packs are installed on your system by running
`locale -a`. I was testing this on an Ubuntu docker image and the only way
I could make it work was to install the language pack. As soon as I did
that and restarted Apache HTTPD, I started to get my translations.

Running `locale -a` on the `cflinuxfs2` docker image shows that only these
language packs are installed.

```
$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
```

When I setup a test app and run it on CF, I get the same results. Only
`en_US.utf8` works.

Unfortunately, I'm not sure how you could go about installing more
language packs into the stack for CF. It seems that you have to install
them via `apt-get` and that simply won't work, since there's no root access
in the container. If anyone has any ideas about how to install more
language packs, let me know.

My only suggestion would be to use the intl extension instead of gettext.
I believe it offers similar functionality, although it's not something I've
done myself.

Hope that helps!

Dan


On Fri, Oct 9, 2015 at 4:47 AM, Hiroaki Ukaji <dt3snow.w(a)gmail.com> wrote:

Hi.
Thanks for your confirmation.
I'm glad that it seems like my intention is being conveyed.
(I'm sorry about my poor English...)

I'm looking forward to hearing a second look from you.


Thanks.

Hiroaki UKAJI



--
View this message in context:
http://cf-dev.70369.x6.nabble.com/cf-dev-PHP-extension-gettext-doesn-t-work-tp1984p2178.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: Disable HTTP transport

Daniel Mikusa
 

See this link.

http://support.run.pivotal.io/entries/82035305-How-do-I-force-my-users-to-use-HTTPS-

Dan


On Sun, Oct 25, 2015 at 5:01 PM, Krzysztof Wilk <chris.m.wilk(a)gmail.com>
wrote:

Hello,

How can I disable HTTP transport of my Spring application deployed to
Pivotal Web Services?

I would like my application be available only through HTTPS transport.

When I run my application in "local mode' (e.g. in Tomcat servlet
container) disabling HTTP transport is simple. It is sufficient to disable
HTTP listener and enable HTTPS listener.

How can I achieve similar effect in Cloud Foundry PWS?

I have skimmed the following security description but found none:
https://docs.cloudfoundry.org/concepts/security.html

I would be grateful for pointing me to relevant documentation.

Best regards,
Krzysztof


mono apps are failed to start in CF

Balaramaraju JLSP <balaramaraju@...>
 

Hi All,

I tried to push .net application [using
https://github.com/cloudfoundry-community/.net-buildpack] to pivotal CF but
is failing with following error. earlier same application used to run with
out any issue.

2015-10-26T11:53:38.000+00:00 [STG] ERR No start command detected; command
must be provided at runtime
2015-10-26T11:53:59.000+00:00 [STG] OUT Uploaded droplet (61.4M)
2015-10-26T11:54:07.000+00:00 [APP] ERR Usage: /tmp/lifecycle/launcher <app
directory> <start command> <metadata>
2015-10-26T11:54:07.000+00:00 [APP] OUT Exit status 1

but same application working with my local cloud foundry (installed 3
months back). I couldn't follow recent changes in CF.

dose any input commands changed recently ?

*cf push command *

cf push OwinFhir -b https://github.com/cloudfoundry-community/.net-buildpack
-m 256M

*cf push log*


Creating app OwinFhir in org MONO / space development as ...
OK

Creating route owinfhir.cfapps.io...
OK

Binding owinfhir.cfapps.io to OwinFhir...
OK

Uploading OwinFhir...
Uploading app files from: D:\Cloud\Git\cf_nise_installer\OwinSamp
Uploading 361.7K, 14 files
OK

Starting app OwinFhir in org MONO / space development as
OK
Creating container
Successfully created container
Downloading app package...
Downloaded app package (1.2M)
Downloading buildpacks (
https://github.com/cloudfoundry-community/.net-buildpack)...
Downloaded buildpacks
Staging...
-----> Downloading Mono runtime 3.4.0_full from
http://ci-labs-buildpack-downloads.s3.amazonaws.com/mono/lucid/x86_64/mono-3.4.0_full.tar.gz
(1.9s)
expanding Mono to vendor/mono (1.6s)
-----> Installing Mozilla certificate data to .config/.mono/certs (1.3s)
-----> Downloading Procfile container current.linux-amd64 from
https://godist.herokuapp.com/projects/ddollar/forego/releases/current/linux-amd64/forego
(1.0s)
-----> Patching Procfile to rename web: to _web: (0.0s)
-----> Preparing AppSettingsAutoReconfiguration.exe (0.0s)
*No start command detected; command must be provided at runtime*
Exit status 0
Staging complete
Uploading droplet, build artifacts cache...
Uploading droplet...
Uploading build artifacts cache...
Uploaded build artifacts cache (59.7M)
Uploaded droplet (61.4M)
Uploading complete

0 of 1 instances running, 1 starting
0 of 1 instances running, 1 starting
0 of 1 instances running
0 of 1 instances running
0 of 1 instances running
Thanks
J L S P Balaramaraju


Re: [abacus] Abacus v0.0.2-rc.2 available

Christopher B Ferris <chrisfer@...>
 

congrats!
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
 

----- Original message -----
From: Jean-Sebastien Delfino <jsdelfino@...>
To: cf-dev@...
Cc:
Subject: [cf-dev] [abacus] Abacus v0.0.2-rc.2 available
Date: Fri, Oct 23, 2015 10:03 PM
 
I'm happy to announce the availability of CF Abacus v0.0.2-rc.2 (incubating).
 
Abacus provides usage metering and aggregation for Cloud Foundry services and app runtimes.
 
This release candidate is for the interested members of the community to get a chance to try Abacus and ask any questions or submit issues and pull requests in the next few days before we cut a final v0.0.2 release.
 
The pre-release Git tag and release notes can be found on Github:
 
The CI build can be found on Travis CI:
 
The npm modules can be found on npmjs:
 
Please feel free to ask any questions about this pre-release of Abacus on this list.
Issues or -- even better -- pull requests are welcome on Github as well!
 
For more info on Abacus please visit:
 
Thanks!
 
- Jean-Sebastien
 


Re: CF-RELEASE v202 UPLOAD ERROR

Amit Kumar Gupta
 

Try some of these diagnostics:
https://docs.cloudfoundry.org/running/troubleshooting.html#bound-timeout
Also, run "bosh vms --details" and "bosh cck --report" and share the
outputs.

On Mon, Oct 26, 2015 at 12:16 AM, Parthiban Annadurai <senjiparthi(a)gmail.com
wrote:
Actually, sorry for the previous mails. Since, I have started with CF v202
release and it thrown some error so am switched to CF v210. But, again
because of some rollback issues we went back with CF v202 itself.
Currently, bosh deploy throws the following, I have attached the Debug Logs
too. Thanks.

Director task 310
Started unknown
Started unknown > Binding deployment. Done (00:00:00)

Started preparing deployment
Started preparing deployment > Binding releases. Done (00:00:00)
Started preparing deployment > Binding existing deployment. Done
(00:00:01)
Started preparing deployment > Binding resource pools. Done (00:00:00)
Started preparing deployment > Binding stemcells. Done (00:00:00)
Started preparing deployment > Binding templates. Done (00:00:00)
Started preparing deployment > Binding properties. Done (00:00:00)
Started preparing deployment > Binding unallocated VMs. Done (00:00:00)
Started preparing deployment > Binding instance networks. Done (00:00:00)

Started preparing package compilation > Finding packages to compile.
Done (00:00:00)

Started preparing dns > Binding DNS. Done (00:00:00)

Started creating bound missing vms
Started creating bound missing vms > medium_z1/0
Started creating bound missing vms > medium_z1/1
Started creating bound missing vms > router_z2/0. Done (00:01:09)
Failed creating bound missing vms > medium_z1/1: Timed out sending
`get_task' to f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds
(00:04:03)
Done creating bound missing vms > medium_z1/0 (00:05:14)
Failed creating bound missing vms (00:05:14)

Error 450002: Timed out sending `get_task' to
f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds

On 24 October 2015 at 06:40, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.

On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote:

Regenerate your manifest.

On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.

On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Parthiban,

Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.

On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

I have created the manifest file using SPIFF tool. Any issues with
that?

On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:

How did you create your manifest in the first place?

On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

After trying the suggestions, now its throws the following error,

Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)

Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')

Could anyone on this??

On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:

Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.

On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Yaa sure Amit. I have attached both the files with this mail.
Could you please? Thanks.



On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io>
wrote:

Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.

On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:

sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.

On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?

Regards

Parthiban A



On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:

Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.

Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties

On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:

hi parthiban

It seems you are running out of space in your vm in which
you are compiling . try to increase the size of memory in your compilation
vm .

regards
Bharath



On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,

Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)

Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe

Could Anyone on this issue?

Regards

Parthiban A

On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:

Hi partiban

can u do a checksum of the tar file .


it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*

example:

*sha1sum {file}*

regards
Bharath

On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:

You actually do not need to download it. if you just run
--

`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>

The director will pull in the release directly from
bosh.io.

--
Thank you,

James Bayer


Re: CF-RELEASE v202 UPLOAD ERROR

Parthiban Annadurai <senjiparthi@...>
 

Actually, sorry for the previous mails. Since, I have started with CF v202
release and it thrown some error so am switched to CF v210. But, again
because of some rollback issues we went back with CF v202 itself.
Currently, bosh deploy throws the following, I have attached the Debug Logs
too. Thanks.

Director task 310
Started unknown
Started unknown > Binding deployment. Done (00:00:00)

Started preparing deployment
Started preparing deployment > Binding releases. Done (00:00:00)
Started preparing deployment > Binding existing deployment. Done
(00:00:01)
Started preparing deployment > Binding resource pools. Done (00:00:00)
Started preparing deployment > Binding stemcells. Done (00:00:00)
Started preparing deployment > Binding templates. Done (00:00:00)
Started preparing deployment > Binding properties. Done (00:00:00)
Started preparing deployment > Binding unallocated VMs. Done (00:00:00)
Started preparing deployment > Binding instance networks. Done (00:00:00)

Started preparing package compilation > Finding packages to compile. Done
(00:00:00)

Started preparing dns > Binding DNS. Done (00:00:00)

Started creating bound missing vms
Started creating bound missing vms > medium_z1/0
Started creating bound missing vms > medium_z1/1
Started creating bound missing vms > router_z2/0. Done (00:01:09)
Failed creating bound missing vms > medium_z1/1: Timed out sending
`get_task' to f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds
(00:04:03)
Done creating bound missing vms > medium_z1/0 (00:05:14)
Failed creating bound missing vms (00:05:14)

Error 450002: Timed out sending `get_task' to
f4dfe4e9-c897-4b9b-b7c7-63a908c10190 after 45 seconds

On 24 October 2015 at 06:40, Parthiban Annadurai <senjiparthi(a)gmail.com>
wrote:

Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.

On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote:

Regenerate your manifest.

On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.

On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Parthiban,

Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.

On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

I have created the manifest file using SPIFF tool. Any issues with
that?

On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:

How did you create your manifest in the first place?

On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

After trying the suggestions, now its throws the following error,

Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)

Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')

Could anyone on this??

On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:

Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.

On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Yaa sure Amit. I have attached both the files with this mail.
Could you please? Thanks.



On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:

Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.

On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:

sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.

On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?

Regards

Parthiban A



On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:

Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.

Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties

On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:

hi parthiban

It seems you are running out of space in your vm in which you
are compiling . try to increase the size of memory in your compilation vm .

regards
Bharath



On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,

Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)

Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe

Could Anyone on this issue?

Regards

Parthiban A

On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:

Hi partiban

can u do a checksum of the tar file .


it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*

example:

*sha1sum {file}*

regards
Bharath

On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:

You actually do not need to download it. if you just run
--

`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>

The director will pull in the release directly from
bosh.io.

--
Thank you,

James Bayer


Delivery failure (sfpj@listserve.uwec.edu)

postmaster@...
 

Your message has encountered delivery problems
to the following recipient(s):

sfpj
(Was addressed to sfpj(a)listserve.uwec.edu)
Delivery failed
The message originator is not a list member



in [115.160.242.246]) by listserve.uwec.edu
(Rockliffe SMTPRA 9.4.1) with ESMTP id <B0061296225(a)listserve.uwec.edu> =
for <sfpj(a)listserve.uwec.edu>;
Mon, 26 Oct 2015 00:21:45 -0500
Message-ID: <B0061296225(a)listserve.uwec.edu>
From: cf-dev(a)lists.cloudfoundry.org
To: sfpj(a)listserve.uwec.edu
Subject: Mail System Error - Returned Mail
Date: Mon, 26 Oct 2015 10:51:32 +0530
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=3D"----=3D_NextPart_000_0009_B71E4C50.64693E54"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000


How to restrict permissions on apps filesystem to protect against remote code upload ?

Guillaume Berche
 

Hi,

Following up onto this thread initiated last year on vcap-dev:

https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org?utm_medium=email&utm_source=footer

Now that user namespaces are supported by garden, and that diego integrated
them as unprivileged containers, I'm wondering if a buildpack compile
script running in unprivileged mode (i.e. within user namespace) would be
able to create namespaced users and groups (say user=apache-owner part of
group=vcap) and to assign file ownership to user apache-owner, only
granting user vcap read+execution permissions to the files ? I yet have to
try this into diego. Anyone tried it ?

If not, can this use-case be considered ?

Searching on the garden docs [0] and tracker, I could only find the
following apparently related stories [1] and [2]

I see diego is currently parsing the user mentionned into the image, but
does not seem making use of it [3]. Maybe something that could be
mentionned into [4] ?

Thanks in advance,

Guillaume.

[0] https://godoc.org/github.com/cloudfoundry-incubator/garden
[1] https://www.pivotaltracker.com/story/show/101501294 I can create an
unprivileged container in a user namespace
[2] https://www.pivotaltracker.com/story/show/101501296 File permissions
are correct in unprivileged containers
[3]
https://github.com/cloudfoundry-incubator/docker_app_lifecycle/blob/8205117b94734a52d1f31bda6fd66168d8fbdc66/builder/builder_runner.go#L93
[4]
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/docker-support.md#docker-deltas

On Mon, Dec 8, 2014 at 4:18 PM, James Bayer wrote:

user namespaces were recently added to garden, so it's likely when diego
is incorporated we'll have those features.

there are no short-term plans to use different types of users in the
staging process afaik, but your suggestions seem reasonable. dieu, mark
kropf and onsi should consider them.

On Wed, Dec 10, 2014 at 5:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

we haven't decided which user to use to run the docker images quite yet.

some docker images will assume a particular user, so just using "vcap" may
exclude some of those from working.

in order to be root, we'd have to be confident that user namespaces
provide adequate security and isolation. user namespaces were recently
added to garden and diego has a story to investigate being able to use root
[1], but i appreciate the importance of your comments on running processes
with least privilege. we'll sort this out as we get closer to running apps
with diego in production.

[1] https://www.pivotaltracker.com/story/show/78606184

On Wed, Dec 10, 2014 at 2:58 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Actually, rather than " use different types of users in the staging
process", this would rather be granting sudo access to the vcap user to be
able to create other users, and chown files to these new users.
Alternatively, have the staging process run as a container "root" user with
permissions to do the previous actions and set default user to run (similar
to USER in docker file [7] ).

By the way, I'm curious how the cf push <docker_image> upcoming feature
will run the docker top process: will that be with run with root (id=0) as
it defaults in docker [7] (or specified USER in docker file) or will it
remains vcap (which would require file permissions on the docker image to
allow world read/execute permissions) ?

[7] https://docs.docker.com/reference/builder/#user
[8] https://docs.docker.com/reference/run/#user

Thanks,

Guillaume.

On Mon, Dec 8, 2014 at 4:18 PM, James Bayer wrote:

user namespaces were recently added to garden, so it's likely when diego
is incorporated we'll have those features.

there are no short-term plans to use different types of users in the
staging process afaik, but your suggestions seem reasonable. dieu, mark
kropf and onsi should consider them.

On Mon, Dec 8, 2014 at 6:25 AM, Guillaume Berche wrote:

Hi,

It's sometimes documented as a best practice [1] [2] to restrict the
permissions on an app executable content in order to limit the cases where
a vulnerable app would allow a remote attacker to upload code on the file
system and use the container resources to run arbitrary code and perform
harm.

In particular, I'm asked whether in the php buildpack (or my custom
fork), I could setup os-level permissions in the buildpack to prevent write
permissions at runtime on potentially executable filesystem locations, e.g.
droplet files to be owned by another user than vcap (say "vcap-stager" that
would be in the vcap group) with read,execute permissions given to vcap
group but no write permissions.

On CloudFoundry, I understand that both the buildpack and the droplet
run with the vcap user (commands run with container-info-buildpack [5]),
with no other user available, nor sudo access to file ownership

$ id vcap
uid=20156(vcap) gid=20156(vcap) groups=20156(vcap)
$ groups vcap

vcap : vcap
$ ls -al /home/vcap
drwxr-xr-x 5 vcap vcap 4096 Dec 8 13:04 .
drwxr-xr-x 3 root root 4096 Dec 8 12:57 ..
$ umask
0077


What would then be best practices on cloudfoundry to prevent remote
code injection from vulnerable apps?

Any plans to support root user during staging, so that custom users
can added at staging time, and secure that with user namespaces similar to
what docker is planning [6] ?

Thanks,

Guillaume.

[1]
http://httpd.apache.org/docs/current/en/misc/security_tips.html#serverroot
[2] http://www.w3.org/Security/faq/wwwsf3.html
[3]
http://docs.cloudfoundry.org/devguide/deploy-apps/environment-variable.html#USER
[4]
https://github.com/cloudfoundry/bosh/blob/master/stemcell_builder/stages/bosh_users/assets/sudoers
[5] https://github.com/cloudfoundry-community/container-info-buildpack
[6]
https://docs.docker.com/articles/security/#docker-daemon-attack-surface
--
You received this message because you are subscribed to the Google
Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/b3690cd8-87cb-4deb-a33c-06e069e46800%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.
To unsubscribe from this group and stop receiving emails from it, send
an email to vcap-dev+unsubscribe(a)cloudfoundry.org.


--
Thank you,

James Bayer
--
You received this message because you are subscribed to a topic in the
Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sVYk4DWx9N8ELCSB1Grr3nyyia4j3hNpo4tcaC7Kvoomw%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sVYk4DWx9N8ELCSB1Grr3nyyia4j3hNpo4tcaC7Kvoomw%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
You received this message because you are subscribed to the Google Groups
"Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/67dc7b50-b3e8-4d2e-b1c6-5e8610727719%40cloudfoundry.org?utm_medium=email&utm_source=footer>
.

To unsubscribe from this group and stop receiving emails from it, send an
email to vcap-dev+unsubscribe(a)cloudfoundry.org.


--
Thank you,

James Bayer
--
You received this message because you are subscribed to a topic in the
Google Groups "Cloud Foundry Developers" group.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sWfSZ-iGDO53ae0%3D-BQV6g4T3v%2B7HDDTMqbvTRgc8DRXg%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/vcap-dev/CAB%3Dt-sWfSZ-iGDO53ae0%3D-BQV6g4T3v%2B7HDDTMqbvTRgc8DRXg%40mail.gmail.com?utm_medium=email&utm_source=footer>
.


Re: Buildpacks PMC - 2015-10-12 Notes

Guillaume Berche
 

Thanks Mike for your response and sorry for delay in following up.
Responses inline.

On Wed, Oct 14, 2015 at 3:18 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:


Related to the architecture epic, What's the outcome of this epic and the
general direction the buildpack team is taking for pluggeable staging
pipeline ?
We're having some discussions now as to next steps. Ideally I'd like to
identify a track of feature work that will drive out a set of features for
extending the buildpack staging lifecycle. If you or anyone else has
suggestions, I'm all ears.
Following are some aspects that were previously discussed and I think
deserve some fixes related to buildpack staging life cycle, what about
setting up a design proposal as suggested by James Bayer into [0] to
detail them with the community ?

- buildpack versionning [b1]
- offer standard caching mechanism for pulled internet dependencies [b2]
- enabling buildpack debugging traces could be standardized across
buildpacks and potentially support added to cf cli and dea, e.g. displaying
last git commits for a custom git repo when debugging is enabled
- heroku compile ENV_DIR compatibility support in diego [b3]
- support for automatically restaging vulnerable apps, once corresponding
buildpacks vulnerabilities are fixed by a new buildpack [b4]
- buildpack governance support: in some organizations, there is a need to
scope some buildpacks per org/spaces, and possibly restrict usage of custom
buildpacks.
- somewhat related, suggesting to improve the droplet download capability
to push the resulting droplet as a docket image into a [private] docker
repo. This might seem more natural than the current download tar.gz droplet
bits followed by a push to the binary buildpack that is suffering from
symlinks uploads portability issues [b5]

[b0]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/mos1CYvnxvAJ
[b1]
http://cf-dev.70369.x6.nabble.com/cf-dev-Droplets-and-Stacks-tp946p2422.html
[b2]
https://groups.google.com/a/cloudfoundry.org/d/msg/vcap-dev/A84xVoi8MmE/AuQt3nF3ImcJ
[b3]
https://github.com/cloudfoundry-incubator/buildpack_app_lifecycle/issues/12
[b4]
https://github.com/cloudfoundry/java-buildpack/issues/231#issuecomment-142200625
[b5] https://www.pivotaltracker.com/n/projects/966314/stories/95890146




The Experiment #5 [3] relying on environment variables POST_BUILDPACK
seems pretty promising. Would it support an orderer list of post buildpacks
?
No reason it couldn't support an ordered set of buildpacks. I'm not fully
convinced this is the best way to proceed, but it's certainly the easiest,
and we're looking at it pretty hard at this point.



Concerning the story "Experiment #6: Investigate using a pluggable / web
services model for extending staging to operators and developers" [1] we
had discussed together into [2]. The story is marked as accepted, but I
can't see the result, and future work, including how this could be exposed
to CF operators or users.
This experiment was cut short, as the "web hook" model introduced too many
reliability concerns, in my opinion, especially around relying on external
services to stage an app. I'm open to revisiting it in the future, but
would like to try more pedestrian solutions first.
Can you please elaborate on your perception of reliability concerns with an
HTTP-based API for staging pipelines ? CloudFoundry currently heavily
relies on (internal) HTTP APIs for its internal workings, or external HTTP
APIs such as the service broker, or the upcoming route services.

What is then the preferred solution for now ? Is the mention of an
S3-API-based pipeline with processes handling their transformation, similar
to the proof-of-concept vito proposed into [p1]

[p1] https://github.com/vito/cfv4 ?





Can you share with the community a summary of learnings from these
experiments and where the "buildpack lifecycle" would be go in the future?
Absolutely, I will do so soon.

If ever you or part of the buildpacks team is making it to the Berlin Cf
Summit, that'd be great to have a community session around this, possibly
in the preceding unconference on sunday.


Re: Droplets and Stacks

Guillaume Berche
 

Thanks Mike for the additional details. Long due PR on buildpacks-docs at
[1]

Dieu, can you please comment on the suggestion above for more fine grained
buildpack versionning support ?

Thanks,

Guillaume.

[1] https://github.com/cloudfoundry/docs-buildpacks/pull/39

On Thu, Aug 6, 2015 at 8:02 PM, Mike Dalessio <mdalessio(a)pivotal.io> wrote:





The /v2/buildpacks endpoint (used by the "cf buildpacks" command)
displays the last update date for a buildpack, e.g.

{
"metadata": {
"guid": "e000b78c-c898-419e-843c-2fd64175527e",
"url": "/v2/buildpacks/e000b78c-c898-419e-843c-2fd64175527e",
"created_at": "2014-04-08T22:05:34Z",
"updated_at": "2015-07-08T23:26:42Z"
},
"entity": {
"name": "java_buildpack",
"position": 3,
"enabled": true,
"locked": false,
"filename": "java-buildpack-v3.1.zip"
}
}

Would'nt it make sense to have the CC increment a version number for each
update so that it becomes easier to query than only relying on dates
comparison ?

While it's great to have buildpacks provide themselves detailed
versionning info for their code and their most important
dependencies/remote artifacts, I feel the cf platform should provide a bit
more support to help identify versions of buildpacks used by apps, such as:
- refine the app summary endpoint [g2]:
- for system buildpacks: include the buildpack guid (in addition to
the buildpack name) as to allow correlation to /v2/buildpacks endpoint
- for custom buildpacks (url): record and display the git hash commit
for a buildpack url
- refine the app listing endpoints [g4] or v3 [g5] to
- support querying app per system buildpack id
- support querying app by dates of "package_updated_at" or best a
version number as suggested above

I'm wondering whether the CAPI team working on API V3 is planning some
work in this area, and could comment the suggestions above.
I'll let Dieu respond to these suggestions, as she's the CAPI PM.


Disable HTTP transport

Krzysztof Wilk
 

Hello,

How can I disable HTTP transport of my Spring application deployed to Pivotal Web Services?

I would like my application be available only through HTTPS transport.

When I run my application in "local mode' (e.g. in Tomcat servlet container) disabling HTTP transport is simple. It is sufficient to disable HTTP listener and enable HTTPS listener.

How can I achieve similar effect in Cloud Foundry PWS?

I have skimmed the following security description but found none:
https://docs.cloudfoundry.org/concepts/security.html

I would be grateful for pointing me to relevant documentation.

Best regards,
Krzysztof


Re: Cloud Foundry Java Client V2

Guillaume Berche
 

Thanks Ben for sharing details of this important effort with the community.

In the light of the ongoing implementation for the v2 cf-java-client
implementation, does the Java experience team feels that of the 300+
documented API endpoints, there is room for a consistent, systematic
approach for the low level API that matches these low-level CC API
endpoints ?

Does the team feel that this low level API could be automatically generated
from a formal REST API specification ?

Could some of the effort in 100% Java coverage could be shifted in
maintaining a formal REST API specification, from which the Java low-level
client could be generated automatically, similar to what google is
systematically doing when providing client libraries [1], in multiple
languages including java [2], php, JS, Node.Js, Go, ruby, .Net for all of
google REST APIs, using automatic client code generation [3].

The question of a formal CC API REST API spec was brought to the CAPI team
in the context of the v3 CC API at [4], and I'd like to know if the teams
generating the clients feel there is room for automation, and mutualization
of effort among programming languages (in particular Java, go, Js) for the
v3 version, building on learnings and experience from existing CC API
clients.

Thanks in advance,

Guillaume.

[1] https://developers.google.com/discovery/libraries?hl=en
[2] https://developers.google.com/api-client-library/java/
[3] https://github.com/google/apis-client-generator
[4] https://github.com/cloudfoundry/cc-api-v3-style-guide/issues/46

On Thu, Oct 15, 2015 at 9:21 PM, Ben Hale <bhale(a)pivotal.io> wrote:

As many of you are aware, the Cloud Foundry Java Client has been a bit
neglected lately. There are various reasons for this, but today I’m
pleased to announce that we’ve begun a V2 effort and that progress is swift.

We on the Cloud Foundry Java Experience team have been aware for some time
that the current implementation of the Java Client is less than ideal.
Among the most common complaints were the lack of separation between
interface and implementation, the subpar network performance, and the
requirement that users understand how to orchestrate common concepts like
`push` on their own. (For a more in-depth treatment of issues we
identified, please see the stellar work done by Scott Fredrick[1].) V2
aims to address all of these issues with a ground-up redesign of the client.

To address the issue of a lack of separation between interface and
implementation, we’ve broken out the API into a project containing no
implementation. This project (`cloudfoundry-client`) consists of a
collection of interfaces and immutable datatypes. There is only a single
dependency, and it isn’t Spring! The intent here was to create an API that
could be implemented with multiple strategies, but requiring the minimal
amount of code for each of those implementations. The API itself is now
reactive (the single dependency is on Reactive Streams, the precursor to
reactive support in Java 9) which we believe will more closely align with
the trends towards non-blocking network communication. We will be
providing a single implementation of this API, based on Spring
(`cloudfoundry-client-spring`) but welcome additional implementations. We
believe we’ve created a good environment for alternatives and would be
happy to hear suggestions on how to improve if that turns out not to be the
case.

In V1, the coverage of the APIs[2] was incomplete (about half, if I had to
guess). Our commitment is to deliver a complete API and implementation in
V2, including all 300+ documented APIs. We’ve observed that this API might
not actually be the right level of abstraction for many users though.
Knowing that you need to create an application, create a package, stage a
droplet, create and start a process, etc. for `push` is quite a burden on
many users of the project. So, we’re also providing a
`cloudfoundry-operations` project that builds on the `cloudfoundry-client`
API but instead of mapping onto the low-level REST API, we’re going to map
roughly onto the `cf` CLI API. We suspect that nearly all users will want
to `cloudFoundryOperations.push()` instead of the low-level alternative, so
both choices are useful. This API and implementation will only depend on
`cloudfoundry-client` allowing any implementation of that API to be used.
Finally, we’ll be bringing the build-system plugins up to date with the
systems that they are built for and ensuring that they cover a breadth of
useful functionality at build time.

This leaves the question about what will happen to V1. We have a
commitment to fixing up the bugs that have been identified in the
code-base, but we’re not going to be doing any work that involves adding
APIs. We feel that users who need those APIs are better served moving to
V2. I’ll be feeding open issues from the backlog into the V2 stream of
work to ensure that we aren’t seeing any resource starvation and you can
expect future releases out of the `1.x` branch.

I hope that this comes as welcome news to the community and look forward
to the feedback. I highly encourage users to keep an eye Pivotal
Tracker[3] to see our progress and submit requests through GitHub[4].


-Ben Hale
Cloud Foundry Java Experience

[1]:
https://docs.google.com/document/d/1Ui-67dBPYoADltErL80xXYEr_INPqdNJG9Va4gPBM-I/edit?usp=sharing
[2]: http://apidocs.cloudfoundry.org/221/
[3]: https://www.pivotaltracker.com/projects/816799
[4]: https://github.com/cloudfoundry/cf-java-client


Re: Diego and Maven support

Krzysztof Wilk
 

Dan,

It seems to me that there is more than one cause of this problem.

I have done the following:
1. upgraded cf CLI from 6.12 to 6.13
2.cf set-health-check MY_APP_NAME none
3. set <healthCheckTimeout>180</healthCheckTimeout> (pom.xml)
4. removed env variables in order to allow Maven to set them again

Still no luck.

However, I have read that there is intensive development of Maven client plugin 2.x happening now. I will give it a try as soon as first release is available.

Best,
Krzysztof


doppler issue which fails to emit logs with syslog protocol on CFv212

Masumi Ito
 

Hi, I am investigating the doppler issue on CFv212 that sending logs to the
external logging service with syslog protocol fails.

As my understanding, the following messages are supposed to be recorded in
the "doppler.stdout.log" if the doppler got the syslog drain url from etcd
successfully.
However it is actually missing.

- Missing log messages which is expected to be shown
{"timestamp":xxxxxx,"process_id":xxxx,"source":"doppler","log_level":"info","message":"Syslog
Sink syslog://xx.xx.xx.xx:xxxx:
Running.","data":null,"file":"/var/vcap/data/compile/doppler/loggregator/src/doppler/sinks/syslog/syslog_sink.go","line":56,"method":"doppler/sinks/syslog.(*SyslogSink).Run"}
{"timestamp":xxxxxx,"process_id":xxxx,"source":"doppler","log_level":"info","message":"Syslog
Sink syslog://xxxxxx:xxxxxx: successfully
connected.","data":null,"file":"/var/vcap/data/compile/doppler/loggregator/src/doppler/sinks/syslog/syslog_sink.go","line":112,"method":"doppler/sinks/syslog.(*SyslogSink).Run"}

Instead, there are a lot of etcd error events found as follows.

{"timestamp":xxxxxxxxx,"process_id":xxx,"source":"doppler","log_level":"error","message":"AppStoreWatcher:
Got error while waiting for ETCD events: store request timed
out","data":null,"file":"/var/vcap/data/compile/doppler/loggregator/src/github.com/cloudfoundry/loggregatorlib/store/app_service_store_watcher.go","line":79,"method":"github.com/cloudfoundry/loggregatorlib/store.(*AppServiceStoreWatcher).Run"}

I have two question about this.

=============
Q1) Does anyone know what this event indicates and how it affects the CF
environment?
In the normal envrionment, is this event still triggered (In other
words, can we ignore this error event messages?)

Q2) If the etcd got some trouble at the moment, which cf component is also
made an influence on?

I guess at the least the following cf components could be affected. Do we
have anyting else?
- router : to support routing api
- hm9000 : to support health check
- doppler: to get syslog drain urls from etcd
- syslog-binder to get syslog drain urls from cc and then store them to
etcd
- trafficcontroller, metron agents : to find healthy dopplers to access
to)
=============

Note that I am also doubting the following errors in the
"syslog_drain_binder.stdout.log".
This message indicates that syslog_drain_binder failed to get syslog drain
urls from cc.
{"timestamp":xxxx,"process_id":xxxx,"source":"syslog_drain_binder","log_level":"error","message":"Error
when polling cloud controller: Remote server error:
Unauthorized","data":null,"file":"/var/vcap/data/compile/syslog_drain_binder/loggregator/src/syslog_drain_binder/main.go","line":68,"method":"main.main"}

Therefore I have not yet concluded the etcd mainly caused the issue, however
need to understand the exact meaning of the error event message above as
well as any impact on the cf envrionment if there is something wrong with
the behaviour of etcd.

Regards,
Masumi



--
View this message in context: http://cf-dev.70369.x6.nabble.com/doppler-issue-which-fails-to-emit-logs-with-syslog-protocol-on-CFv212-tp2418.html
Sent from the CF Dev mailing list archive at Nabble.com.


Re: CF-RELEASE v202 UPLOAD ERROR

Parthiban Annadurai <senjiparthi@...>
 

Thanks Amit for your suggestions. Let you know after regenerating the
manifest again.

On 24 October 2015 at 11:47, Amit Gupta <agupta(a)pivotal.io> wrote:

Regenerate your manifest.

On Fri, Oct 23, 2015 at 10:49 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Okay Amit. Yaa, I changed my CF Version from v202 to v210. Could you
share that metron_agent.deployment property of the manifest which is
required in v210? Thanks.

On 24 October 2015 at 10:57, Amit Gupta <agupta(a)pivotal.io> wrote:

Parthiban,

Your log.txt shows that you're using cf-release version 210, but your
subject message says you're trying v202. Perhaps you've checked out v202
of cf-release and used the spiff tooling to generate the manifests from
that version. v202 doesn't include the metron_agent.deployment property in
its manifest, which is required in v210.

On Fri, Oct 23, 2015 at 10:07 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

I have created the manifest file using SPIFF tool. Any issues with that?

On 23 October 2015 at 20:49, Amit Gupta <agupta(a)pivotal.io> wrote:

How did you create your manifest in the first place?

On Fri, Oct 23, 2015 at 8:17 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

After trying the suggestions, now its throws the following error,

Started preparing configuration > Binding configuration. Failed:
Error filling in template `metron_agent.json.erb' for `ha_proxy_z1/0' (line
5: Can't find property `["metron_agent.deployment"]') (00:00:00)

Error 100: Error filling in template `metron_agent.json.erb' for
`ha_proxy_z1/0' (line 5: Can't find property `["metron_agent.deployment"]')

Could anyone on this??

On 22 October 2015 at 18:08, Amit Gupta <agupta(a)pivotal.io> wrote:

Try running "bosh cck" and recreating VMs from last known apply
spec. You should also make sure that the IPs you're allocating to your
jobs are accessible from the BOSH director VM.

On Thu, Oct 22, 2015 at 5:27 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Yaa sure Amit. I have attached both the files with this mail. Could
you please? Thanks.



On 21 October 2015 at 19:49, Amit Gupta <agupta(a)pivotal.io> wrote:

Can you share the output of "bosh vms" and "bosh task 51
--debug". It's preferable if you copy the terminal outputs and paste them
to Gists or Pastebins and share the links.

On Tue, Oct 20, 2015 at 6:18 AM, James Bayer <jbayer(a)pivotal.io>
wrote:

sometimes a message like that is due to networking issues. does
the bosh director and the VM it is creating have an available network path
to reach each other? sometimes ssh'ing in to the VM that is identified can
yield more debug clues.

On Tue, Oct 20, 2015 at 5:09 AM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Thanks Bharath and Amit for the helpful solutions. I have
surpassed that error. Now, bosh deploy strucks like in attached image.
Could you anyone please?

Regards

Parthiban A



On 20 October 2015 at 11:57, Amit Gupta <agupta(a)pivotal.io>
wrote:

Bharath, I think you mean to increase the *disk* size on the
compilation VMs, not the memory size.

Parthiban, the error message is happening during compiling,
saying "No space left on device". This means your compilation VMs are
running out of space on disk. This means you need to increase the
allocated disk for your compilation VMs. In the "compilation" section of
your deployment manifest, you can specify "cloud_properties". This is
where you will specify disk size. These "cloud_properties" look the same
as the could_properties specified for a resource pool. Depending on your
IaaS, the structure of the cloud_properties section differs. See here:
https://bosh.io/docs/deployment-manifest.html#resource-pools-cloud-properties

On Mon, Oct 19, 2015 at 11:13 PM, Bharath Posa <
bharathp(a)vedams.com> wrote:

hi parthiban

It seems you are running out of space in your vm in which you
are compiling . try to increase the size of memory in your compilation vm .

regards
Bharath



On Mon, Oct 19, 2015 at 7:39 PM, Parthiban Annadurai <
senjiparthi(a)gmail.com> wrote:

Hello All,
Thanks All for the helpful suggestions.
Actually, now we r facing the following issue while kicking bosh deploy,

Done compiling packages >
nats/d3a1f853f4980682ed8b48e4706b7280e2b7ce0e (00:01:07)
Failed compiling packages >
buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157: Action Failed
get_task: Task aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling
package buildpack_php: Compressing compiled package: Shelling out to tar:
Running command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe (00:02:41)
Failed compiling packages (00:02:41)

Error 450001: Action Failed get_task: Task
aba21e6a-2031-4a69-5b72-f238ecd07051 result: Compiling package
buildpack_php: Compressing compiled package: Shelling out to tar: Running
command: 'tar czf
/var/vcap/data/tmp/bosh-platform-disk-TarballCompressor-CompressFilesInDir762165297
-C
/var/vcap/data/packages/buildpack_php/9c72be716ab8629d7e6feed43012d1d671720157.1-
.', stdout: '', stderr: '
gzip: stdout: No space left on device
': signal: broken pipe

Could Anyone on this issue?

Regards

Parthiban A

On 19 October 2015 at 14:30, Bharath Posa <
bharathp(a)vedams.com> wrote:

Hi partiban

can u do a checksum of the tar file .


it should come like this *sha1:
b6f596eaff4c7af21cc18a52ef97e19debb00403*

example:

*sha1sum {file}*

regards
Bharath

On Mon, Oct 19, 2015 at 1:12 PM, Eric Poelke <
epoelke(a)gmail.com> wrote:

You actually do not need to download it. if you just run --

`bosh upload release
https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202`
<https://bosh.io/d/github.com/cloudfoundry/cf-release?v=202>

The director will pull in the release directly from bosh.io
.

--
Thank you,

James Bayer

6981 - 7000 of 9426