|
I'm pleased to announce the release of the java-buildpack, version 3.3.1. This release contains a new debug framework and ensures that the dependencies contained in the offline buildpack are up to date. For a more detailed look at the changes in 3.3.1, please take a look at the commit log < https://github.com/cloudfoundry/java-buildpack/compare/v3.3...v3.3.1>. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release < https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.3.1>. *Packaged Dependencies* - AppDynamics Agent: 4.1.5_3 - GemFire 8.0.0 - GemFire Modules 8.0.0.1 - GemFire Modules Tomcat7 8.0.0.1 - GemFire Security 8.0.0 - Groovy: 2.4.5 - JRebel 6.2.6 - MariaDB JDBC: 1.2.3 - Memory Calculator (mountainlion): 2.0.0.RELEASE - Memory Calculator (precise): 2.0.0.RELEASE - Memory Calculator (trusty): 2.0.0.RELEASE - New Relic Agent: 3.21.0 - OpenJDK JRE (mountainlion): 1.8.0_65 - OpenJDK JRE (precise): 1.8.0_65 - OpenJDK JRE (trusty): 1.8.0_65 - Play Framework JPA Plugin: 1.10.0.RELEASE - PostgreSQL JDBC: 9.4.1204 - RedisStore: 1.2.0_RELEASE - Spring Auto-reconfiguration: 1.10.0_RELEASE - Spring Boot CLI: 1.2.7_RELEASE - Tomcat Access Logging Support: 2.4.0_RELEASE - Tomcat Lifecycle Support: 2.4.0_RELEASE - Tomcat Logging Support: 2.4.0_RELEASE - Tomcat: 8.0.28 Christopher Frost - Pivotal UK Java Buildpack Team
|
|
|
Re: mono apps are failed to start in CF
Hi,
as I see this buildpack is for lucid64 stack. PWS now uses cflinuxfs2 stack. This inconsistency can be the source of your problem.
Can you verify stack on your local CF using `cf stacks`?
Alex Zalesov
|
|
|
Re: Permission denied error when unpacking droplet
Aliaksei Makarevich <snork.mitzumi@...>
I have the same problem with Stacks. Changing permissions manually to openworld RW don't change a thing. Has anyone else faced such issue?
{"timestamp":1445792695.6604235,"message":"run (took 1.328794)","log_level":"debug","source":"Warden::Container::Linux","data":{"handle":"192u2he1nqp","request":{"handle":"192u2he1nqp","script":"cd /home/vcap/ && tar zxf /var/vcap/data/dea_next/droplets/3c3efe6dcad047fafda0495897069a0867277e5a/droplet.tgz"},"response":{"exit_status":2,"stdout":"","stderr":"tar: ./staging_info.yml: Cannot open: Permission denied\ntar: ./logs: Cannot mkdir: Permission denied\ntar: ./logs: Cannot mkdir: Permission denied\ntar: ./logs/staging_task.log: Cannot open: No such file or directory\ntar: ./tmp: Cannot mkdir: Permission denied\ntar: .: Cannot utime: Operation not permitted\ntar: Exiting with failure status due to previous errors\n","info":"#<Warden::Protocol::InfoResponse:0x007fc470870be0>"}},"thread_id":70240825357100,"fiber_id":70240831615120,"process_id":17093,"file":"/var/vcap/data/packages/warden/88b0ad837f313990ce408e50cd904f7025983213.1-358cd8f2e7dedc2e0f4d86f7234b1bc21e82314d/warden/lib/warden/container/base.rb","...
|
|
|
Re: How to get a new UAA guid by REST
Hi,
you need to query UAA API instead of CC API to learn user id.
GET /Users?attributes=id&filter=userName eq 'admin'
UAA endpoint:
$ cat ~/.cf/config.json | jq .UaaEndpoint
To create user you still need to use CC API, as user data goes to both CC and UAA databases. CC then creates UAA user automatically.
|
|
|
Re: How to get a new UAA guid by REST
toggle quoted message
Show quoted text
On Oct 26, 2015, at 7:38 AM, Juan Antonio Breña Moral <bren(a)juanantonio.info> wrote:
Hi,
I would like to create users using REST API:
http://apidocs.cloudfoundry.org/222/users/creating_a_user.html
But I don't know how to get a UAA guid of the user to create:
guid-896216bb-a73f-48c1-9824-9c796ad36b7c
How to get it?
Many thanks in advance.
Juan Antonio
|
|
|
How to get a new UAA guid by REST
Juan Antonio Breña Moral <bren at juanantonio.info...>
|
|
|
Re: Diego and Maven support
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.
toggle quoted message
Show quoted text
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?
Mike,
That sounds good. Happy to retest after that work has been done and
confirm it resolves the issue here.
Dan
toggle quoted message
Show quoted text
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...>
|
|
|
Re: PHP extension 'gettext' doesn't work?
toggle quoted message
Show quoted text
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
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@...>
toggle quoted message
Show quoted text
----- 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! Â
Â
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
toggle quoted message
Show quoted text
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)
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=footerNow 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-deltasOn 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.
|
|
|
