Date   

Re: Manifests for Postgressql , Mongodb

Dr Nic Williams <drnicwilliams@...>
 

For Mongo/PostgresSQL there a couple options:
* docker-boshrelease and configure the PG/Mongo/whatever services you want; these are Dev services - no backups let alone continuous archiving; no HA* https://github.com/dingotiles/dingo-postgresql-release provides clusters of HA PG, with continuous archiving to remote object store
I'm unsure about MongoDB service brokers with continous archiving & HA. Perhaps enquirer with Anynines who may have a commercial solution.
For the two bullet points above, there are not Azure specific templates but if you know enough about Azure then you can insert the specific Azure bits in lieu of the Warden template.
Or ping me direct to figure out where you're at and what help you need.

CheersDr Nic

On Wed, Oct 5, 2016 at 3:43 AM +1000, "vijay kumar Mattewada" <matt.vijay(a)gmail.com> wrote:










Hi Team,

How are you?
I need help  related to cloud foundry stuff.
I need to deploy postgressql , mongodb using manifest on azure bosh cloudfoundry.
Please share the manifest for the deployments related to postgres and mongodb services.
Please suggest me.


RegardsVijay


Re: Failure of all metron_agents in Cloudfoundry

Sylvain Goulmy <sygoulmy@...>
 

Hi Dan,

Thank you for your feedback.

Everything was working fine except the metron_agent job on each VM.

Actually we solved that issue by restart the etcd. We have three etcd
servers, the first restart (monit restart all) didn't change anything (all
the jobs were restarted except the metron_agent), but by restarting the
second one everything went fine again and all the metron_agent went up and
running again on each VM.

I have also checked the etcd table content (before restarting) and
everything looked fine.

Unfortunetely we haven't understood the root cause of that behaviour that
already happened before.

Sylvain

On Tue, Oct 4, 2016 at 5:30 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

If the ETCD servers are working, you might try restarting your dopplers.
The dopplers register in ETCD and Metron looks at ETCD to locate the
dopplers. If ETCD is working and you're getting this message, it could be
that there are no registered dopplers. Restarting the dopplers will cause
them to register again.

Hope that helps!

Dan

On Tue, Oct 4, 2016 at 10:12 AM, Eric Boucherie <erboucherie(a)airfrance.fr>
wrote:

Hi all , i had a strange behaviour happening on our CloudFoundry platform
(v237 running on OpenStack) .
All metron_agents (for all Vms) were failing to start with the same
following error in the log file :

goroutine 31 [running]:
panic(0x9dca60, 0xc8201a6060)
/var/vcap/data/packages/golang1.6/85a489b7c0c2584aa9e0a6dd83
666db31c6fc8e8.1-1857aa617c2de427d5ece149206ba48dda411635/src/runtime/panic.go:464
+0x3e6
metron/clientreader.Read(0xc820107ce0, 0xc82013e280, 0x1, 0x1, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, ...)
/var/vcap/data/compile/metron_agent/loggregator/src/metron/c
lientreader/client_reader.go:17 +0x22b
main.initializeDopplerPool.func1(0xc820107ce0, 0xc82013e280, 0x1, 0x1,
0xc82006a870, 0xc8200b99c0, 0xc820107dd0, 0xc820107d10)
/var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:180
+0xe9
created by main.initializeDopplerPool
/var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:184
+0xc9e
panic: No dopplers listening on [udp]

I looked at the Doppler process log , and everything looked fine .
I presumed that the error could come from etcd servers but i couldn't see
any relevant errors in their logs .
So has anyone an idea of the reason of that error ?

Thanks in advance .
Eric


Re: Failure of all metron_agents in Cloudfoundry

Daniel Mikusa
 

If the ETCD servers are working, you might try restarting your dopplers.
The dopplers register in ETCD and Metron looks at ETCD to locate the
dopplers. If ETCD is working and you're getting this message, it could be
that there are no registered dopplers. Restarting the dopplers will cause
them to register again.

Hope that helps!

Dan

On Tue, Oct 4, 2016 at 10:12 AM, Eric Boucherie <erboucherie(a)airfrance.fr>
wrote:

Hi all , i had a strange behaviour happening on our CloudFoundry platform
(v237 running on OpenStack) .
All metron_agents (for all Vms) were failing to start with the same
following error in the log file :

goroutine 31 [running]:
panic(0x9dca60, 0xc8201a6060)
/var/vcap/data/packages/golang1.6/85a489b7c0c2584aa9e0a6dd83666d
b31c6fc8e8.1-1857aa617c2de427d5ece149206ba48dda411635/src/runtime/panic.go:464
+0x3e6
metron/clientreader.Read(0xc820107ce0, 0xc82013e280, 0x1, 0x1, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, ...)
/var/vcap/data/compile/metron_agent/loggregator/src/metron/
clientreader/client_reader.go:17 +0x22b
main.initializeDopplerPool.func1(0xc820107ce0, 0xc82013e280, 0x1, 0x1,
0xc82006a870, 0xc8200b99c0, 0xc820107dd0, 0xc820107d10)
/var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:180
+0xe9
created by main.initializeDopplerPool
/var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:184
+0xc9e
panic: No dopplers listening on [udp]

I looked at the Doppler process log , and everything looked fine .
I presumed that the error could come from etcd servers but i couldn't see
any relevant errors in their logs .
So has anyone an idea of the reason of that error ?

Thanks in advance .
Eric


Failure of all metron_agents in Cloudfoundry

Eric Boucherie
 

Hi all , i had a strange behaviour happening on our CloudFoundry platform (v237 running on OpenStack) .
All metron_agents (for all Vms) were failing to start with the same following error in the log file :

goroutine 31 [running]:
panic(0x9dca60, 0xc8201a6060)
/var/vcap/data/packages/golang1.6/85a489b7c0c2584aa9e0a6dd83666db31c6fc8e8.1-1857aa617c2de427d5ece149206ba48dda411635/src/runtime/panic.go:464 +0x3e6
metron/clientreader.Read(0xc820107ce0, 0xc82013e280, 0x1, 0x1, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/var/vcap/data/compile/metron_agent/loggregator/src/metron/clientreader/client_reader.go:17 +0x22b
main.initializeDopplerPool.func1(0xc820107ce0, 0xc82013e280, 0x1, 0x1, 0xc82006a870, 0xc8200b99c0, 0xc820107dd0, 0xc820107d10)
/var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:180 +0xe9
created by main.initializeDopplerPool
/var/vcap/data/compile/metron_agent/loggregator/src/metron/main.go:184 +0xc9e
panic: No dopplers listening on [udp]

I looked at the Doppler process log , and everything looked fine .
I presumed that the error could come from etcd servers but i couldn't see any relevant errors in their logs .
So has anyone an idea of the reason of that error ?

Thanks in advance .
Eric


Re: Forwrad container metrics to syslog drain

Geoff Franks <geoff@...>
 

Have you taken a look at firehose-to-syslog (https://github.com/cloudfoundry-community/firehose-to-syslog)?

On Oct 4, 2016, at 8:59 AM, Carlo Alberto Ferraris <carlo.ferraris(a)rakuten.com> wrote:

Will just drop this here in case somebody wants to add something: https://github.com/cloudfoundry/loggregator/issues/150


Re: Forwrad container metrics to syslog drain

Carlo Alberto Ferraris
 

Will just drop this here in case somebody wants to add something: https://github.com/cloudfoundry/loggregator/issues/150


Forwrad container metrics to syslog drain

Mehran Saliminia
 

Hi,

does anybody know what is the best way to forward container metrics to a user-specified syslog drain?


Re: DNS and the blobstore

Benjamin Gandon
 

The .cf.internal DNS domain is taken over by Consul directly whereas DNS requests for all other domains are forwarded to "recursors", which are the external DNS servers used by your bosh deployment.

The config for Consul is mostly handled by a golang shim named "confab", instead of Bosh.

/Benjamin

Le 29 août 2016 à 15:49, Neil Watson <neil(a)watson-wilson.ca> a écrit :

From http://docs.cloudfoundry.org/deploying/common/vsphere-vcloud-cf-stub.html "Note: vSphere defaults to using an internal WebDAV blobstore for the Cloud Controller. " Then the spiff merge creates an internal URL for the blobstore: "blobstore.service.cf.internal". Then I see the api server doing a DNS lookup for that URL. Where is that DNS record defined?


Need to deploy cassandra , Kafka services

rohit chilkuri <saayaan5566@...>
 

Hi all,


I am currently working cloudfoundry and need to deploy cassandra, kafka
services

on azure using bosh cloudfoundry.

I need help for getting manifest for these services.

please share me the manifest for the deployment.



Regards,
joseph.


Manifests for Postgressql , Mongodb

vijay kumar Mattewada <matt.vijay@...>
 

Hi Team,


How are you?

I need help related to cloud foundry stuff.

I need to deploy postgressql , mongodb using manifest on azure bosh
cloudfoundry.

Please share the manifest for the deployments related to postgres and
mongodb services.

Please suggest me.



Regards
Vijay


dea-spare is not getting deleted when deleting bosh deployment

Vikram Ranabhatt
 

I am using bosh-init bosh-257.9 ,bosh-openstack-cpi-27,stemcell 3262.2. and cf233.I am able to deploy cloudfoundry.
when i try to delete it it gets stuck at dea-spare.

+----------------------------------------------------+---------+-----+-------------------+------------+
| VM | State | AZ | VM Type | IPs |
+----------------------------------------------------+---------+-----+-------------------+------------+
| dea-spare/0 (a69a345c-179a-451d-8a68-cc6ce211f866) | failing | n/a | dea-spare-xlarge | 10.40.1.40 |
| dea-spare/1 (2ef2f485-3756-4710-8db4-2a86392b6f92) | failing | n/a | dea-spare-xlarge | 10.40.1.41 |
| dea-spare/2 (c4de7875-e7aa-4468-ad5e-6924037ad64d) | failing | n/a | dea-spare-xlarge | 10.40.1.42 |
| kafka/0 (10c32a83-2031-4bbf-9901-591f9c33ef59) | running | n/a | service-net-large | 10.40.1.52 |
| kafka/2 (6d293508-2449-4a94-9c40-9fb1d6d295a3) | running | n/a | service-net-large | 10.40.1.53 |
| redis/0 (119a8e08-eff2-49db-a172-65d6f410a506) | running | n/a | service-net-large | 10.40.1.51 |
+----------------------------------------------------+---------+-----+-------------------+------------+

Drain script output

I, [2016-10-03T13:25:13.866823 #4954] INFO -- : Sending signal USR2 to DEA.
I, [2016-10-03T13:25:13.891322 #4954] INFO -- : Hey BOSH, call me back in 5s.
I, [2016-10-03T13:25:18.906620 #4957] INFO -- : Drain script invoked with job_check_status hash_unchanged
I, [2016-10-03T13:25:18.906738 #4957] INFO -- : Sending signal USR2 to DEA.
I, [2016-10-03T13:25:18.915465 #4957] INFO -- : Hey BOSH, call me back in 5s.
I, [2016-10-03T13:25:23.933589 #4960] INFO -- : Drain script invoked with job_check_status hash_unchanged
I, [2016-10-03T13:25:23.933767 #4960] INFO -- : Sending signal USR2 to DEA.
I, [2016-10-03T13:25:23.955843 #4960] INFO -- : Hey BOSH, call me back in 5s.
I, [2016-10-03T13:25:28.973586 #4963] INFO -- : Drain script invoked with job_check_status hash_unchanged
I, [2016-10-03T13:25:28.973768 #4963] INFO -- : Sending signal USR2 to DEA.


dea_next.log

{"timestamp":1475501048.5344489,"message":"Evacuating (first time: true; can shutdown: true)","log_level":"info","source":"EvacuationHandler","data":{},"thread_id":47126037166480,"fiber_id":47126053691560,"process_id":4574,"file":"/var/vcap/packages/dea_next/lib/dea/lifecycle/evacuation_handler.rb","lineno":15,"method":"evacuate!"}
{"timestamp":1475501048.5347793,"message":"All instances and staging tasks stopped, exiting.","log_level":"info","source":"Dea::Bootstrap","data":{},"thread_id":47126037166480,"fiber_id":47126053691560,"process_id":4574,"file":"/var/vcap/packages/dea_next/lib/dea/lifecycle/shutdown_handler.rb","lineno":46,"method":"flush_message_bus_and_terminate"}
{"timestamp":1475501053.55335,"message":"caught SIGUSR2","log_level":"warn","source":"Dea::Bootstrap","data":{},"thread_id":47126037166480,"fiber_id":47126053691560,"process_id":4574,"file":"/var/vcap/packages/dea_next/lib/dea/lifecycle/signal_handler.rb","lineno":25,"method":"block (3 levels) in setup"}
{"timestamp":1475501053.5535686,"message":"Evacuating (first time: false; can shutdown: true)","log_level":"info","source":"EvacuationHandler","data":{},"thread_id":47126037166480,"fiber_id":47126053691560,"process_id":4574,"file":"/var/vcap/packages/dea_next/lib/dea/lifecycle/evacuation_handler.rb","lineno":15,"method":"evacuate!"}
{"timestamp":1475501058.5688045,"message":"caught SIGUSR2","log_level":"warn","source":"Dea::Bootstrap","data":{},"thread_id":47126037166480,"fiber_id":47126053691560,"process_id":4574,"file":"/var/vcap/packages/dea_next/lib/dea/lifecycle/signal_handler.rb","lineno":25,"method":"block (3 levels) in setup"}


Re: Announcement: default etcd cluster to TLS in cf-release spiff templates

Adrian Zankich
 

Hi Michael,

Have you tried Rich's suggestion: https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/MPUKXCBNG7H642ITVYKRMQ5ZQ6YLJKDU/

- Adrian


Re: Facing problem while pushing Spring Boot app on PCF

Mike Dalessio
 

Worth noting that we recommend using cloudfoundry/binary-buildpack in place
of the community null-buildpack. The `binary-buildpack` is supported by the
core OSS team, and does not suffer from this always-detect behavior.

On Fri, Sep 30, 2016 at 10:25 AM, Mike Dalessio <mdalessio(a)pivotal.io>
wrote:

Ah, you're absolutely right -- my mistake. That makes sense, then.

On Fri, Sep 30, 2016 at 4:16 AM, John Feminella <jxf(a)pivotal.io> wrote:

But the null buildpack should never be detected:

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/detect
My reading of this is "the null buildpack is *always* detected". I
thought a buildpack was detected if it returns 0:

https://docs.cloudfoundry.org/buildpacks/custom.html#detect-script


On Wed, Sep 28, 2016, 10:50 Mike Dalessio <mdalessio(a)pivotal.io> wrote:

There's still something weird going on ...

We know that buildpack detection is happening, because we see all the
buildpacks being fetched by Diego in the log.

But the null buildpack should never be detected:

https://github.com/ryandotsmith/null-buildpack/blob/
master/bin/detect

Also, it would mean the null buildpack was set as an admin buildpack
(which it wouldn't be by default on PCF) ... it sounds like this CF
installation has been mucked around with from the sane default
configuration.



On Wed, Sep 28, 2016 at 10:33 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

Disregard what I said earlier. I think John's right. The output from
staging is showing...

Staging...
-----> Nothing to do.
That looks like it could be coming from the null-buildpack.

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/compile

So try specifying `-b java_buildpack_offline` to `cf push` or
`buildpack: java_buildpack_offline` in your manifest.yml. That will force
it to use the JBP. Then see what happens. Like John said, there might be
something off with the JAR file that you also need to fix.

Dan



On Wed, Sep 28, 2016 at 10:01 AM, John Liptak <john.h.liptak(a)gmail.com>
wrote:

I would also specify the java buildpack. If there is a structural
problem in your jar file, the java buildpack may not be detecting it as a
Java application and some other buildpack is attempting to package it.
Generally, spring boot applications and Java buildpacks should have a start
command.

John

On Wed, Sep 28, 2016 at 6:09 AM Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

What is the system you are targeting? For example, a bosh lite
install, PCF-dev, PWS, Bluemix, other? If it's a system you deployed,
which CF Release & Diego release are you using?

Also, can you push *any* applications to it successfully? Maybe try
a few samples from here [1] and see if any of them work.

2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**

It's this output that has me concerned. You might also want to check
the cell logs to see if there's any additional output on why the launcher
is failing or what arguments it's being given (that it clearly doesn't
like).

Dan

[1] - https://github.com/cloudfoundry-samples/



On Wed, Sep 28, 2016 at 3:44 AM, Mohan V <mohan221213(a)gmail.com>
wrote:

I am trying to push the simple spring boot app in pcf.
I am completely new to pcf.
I was created manifest.yml file which contain following data:-

applications:
- name: PivotalPushTest
host: PivotalPushTest
memory: 512M
instances: 1
path: /root/Desktop/PivotalPushTest/target/PivotalPustTest-0.0.1-S
NAPSHOT.jar

but when I am pushing this app via cf push command I am getting
following error:-

cf push
Using manifest file /root/Desktop/PivotalPushTest/manifest.yml

Creating app PivotalPushTest in org ORGNAME / space Java-Hadoop as
username(a)domainname.com...
OK

Using route PivotalPushTest.url.com
Binding PivotalPushTest.url.com to PivotalPushTest...
OK

Uploading PivotalPushTest...
Uploading app files from: /tmp/unzipped-app911037164
Uploading 6.1K, 16 files
Done uploading
OK

Starting app PivotalPushTest in org ORGNAME / space Java-Hadoop as
username(a)domainname.com...
Downloading python_buildpack...
Downloading php_buildpack...
Downloading java_buildpack_offline...
Downloading null_buildpack...
Downloading go_buildpack_1-6...
Downloading staticfile_buildpack...
Downloading binary_buildpack...
Downloading ruby_buildpack...
Downloading nodejs_buildpack...
Downloading go_buildpack...
Downloaded python_buildpack
Downloaded nodejs_buildpack
Downloaded binary_buildpack
Downloaded php_buildpack
Downloaded go_buildpack
Downloaded go_buildpack_1-6
Downloaded ruby_buildpack
Downloaded java_buildpack_offline
Downloaded null_buildpack
Downloaded staticfile_buildpack
Creating container
Successfully created container
Downloading app package...
Downloaded app package (6.6K)
Staging...
-----> Nothing to do.
**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 (109B)
Uploaded droplet (3.7K)
Uploading complete

0 of 1 instances running, 1 crashed
FAILED
Error restarting application: Start unsuccessful

TIP: use 'cf logs PivotalPushTest --recent' for more information

In Apps Manager Logs:-
OUT Exit status 1
2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**
2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2
2016-09-28T07:05:58.000+00:00 [API] OUT App instance exited with
guid 637a95a7-4def-4c43-b00e-454ca6f584f8 payload:
{"instance"=>"460e1817-d616-495e-407e-49991b0026b0", "index"=>0,
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2
error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled",
"crash_count"=>1, "crash_timestamp"=>1475046358426721004,
"version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"}
2016-09-28T07:05:58.000+00:00 [CELL] OUT Creating container
2016-09-28T07:05:58.000+00:00 [CELL] OUT Successfully created
container
2016-09-28T07:05:58.000+00:00 [CELL] OUT Starting health monitoring
of container
2016-09-28T07:05:58.000+00:00 [APP] OUT Exit status 1
2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**
2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2
2016-09-28T07:05:59.000+00:00 [API] OUT App instance exited with
guid 637a95a7-4def-4c43-b00e-454ca6f584f8 payload:
{"instance"=>"06f0d873-0050-4e66-6bc8-11ec83ec369f", "index"=>0,
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2
error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled",
"crash_count"=>2, "crash_timestamp"=>1475046358988785723,
"version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"}
2016-09-28T07:05:59.000+00:00 [CELL] OUT Creating container
2016-09-28T07:05:59.000+00:00 [CELL] OUT Successfully created
container
2016-09-28T07:05:59.000+00:00 [CELL] OUT Starting health monitoring
of container
2016-09-28T07:05:59.000+00:00 [APP] OUT Exit status 1
2016-09-28T07:05:59.000+00:00 [APP] ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>
2016-09-28T07:05:59.000+00:00 [CELL] OUT Exit status 2

Please Help,
Mohan V.


Re: Facing problem while pushing Spring Boot app on PCF

Mike Dalessio
 

Ah, you're absolutely right -- my mistake. That makes sense, then.

On Fri, Sep 30, 2016 at 4:16 AM, John Feminella <jxf(a)pivotal.io> wrote:

But the null buildpack should never be detected:

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/detect
My reading of this is "the null buildpack is *always* detected". I thought
a buildpack was detected if it returns 0:

https://docs.cloudfoundry.org/buildpacks/custom.html#detect-script


On Wed, Sep 28, 2016, 10:50 Mike Dalessio <mdalessio(a)pivotal.io> wrote:

There's still something weird going on ...

We know that buildpack detection is happening, because we see all the
buildpacks being fetched by Diego in the log.

But the null buildpack should never be detected:

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/detect

Also, it would mean the null buildpack was set as an admin buildpack
(which it wouldn't be by default on PCF) ... it sounds like this CF
installation has been mucked around with from the sane default
configuration.



On Wed, Sep 28, 2016 at 10:33 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

Disregard what I said earlier. I think John's right. The output from
staging is showing...

Staging...
-----> Nothing to do.
That looks like it could be coming from the null-buildpack.

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/compile

So try specifying `-b java_buildpack_offline` to `cf push` or
`buildpack: java_buildpack_offline` in your manifest.yml. That will force
it to use the JBP. Then see what happens. Like John said, there might be
something off with the JAR file that you also need to fix.

Dan



On Wed, Sep 28, 2016 at 10:01 AM, John Liptak <john.h.liptak(a)gmail.com>
wrote:

I would also specify the java buildpack. If there is a structural
problem in your jar file, the java buildpack may not be detecting it as a
Java application and some other buildpack is attempting to package it.
Generally, spring boot applications and Java buildpacks should have a start
command.

John

On Wed, Sep 28, 2016 at 6:09 AM Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

What is the system you are targeting? For example, a bosh lite
install, PCF-dev, PWS, Bluemix, other? If it's a system you deployed,
which CF Release & Diego release are you using?

Also, can you push *any* applications to it successfully? Maybe try a
few samples from here [1] and see if any of them work.

2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**

It's this output that has me concerned. You might also want to check
the cell logs to see if there's any additional output on why the launcher
is failing or what arguments it's being given (that it clearly doesn't
like).

Dan

[1] - https://github.com/cloudfoundry-samples/



On Wed, Sep 28, 2016 at 3:44 AM, Mohan V <mohan221213(a)gmail.com>
wrote:

I am trying to push the simple spring boot app in pcf.
I am completely new to pcf.
I was created manifest.yml file which contain following data:-

applications:
- name: PivotalPushTest
host: PivotalPushTest
memory: 512M
instances: 1
path: /root/Desktop/PivotalPushTest/target/PivotalPustTest-0.0.1-
SNAPSHOT.jar

but when I am pushing this app via cf push command I am getting
following error:-

cf push
Using manifest file /root/Desktop/PivotalPushTest/manifest.yml

Creating app PivotalPushTest in org ORGNAME / space Java-Hadoop as
username(a)domainname.com...
OK

Using route PivotalPushTest.url.com
Binding PivotalPushTest.url.com to PivotalPushTest...
OK

Uploading PivotalPushTest...
Uploading app files from: /tmp/unzipped-app911037164
Uploading 6.1K, 16 files
Done uploading
OK

Starting app PivotalPushTest in org ORGNAME / space Java-Hadoop as
username(a)domainname.com...
Downloading python_buildpack...
Downloading php_buildpack...
Downloading java_buildpack_offline...
Downloading null_buildpack...
Downloading go_buildpack_1-6...
Downloading staticfile_buildpack...
Downloading binary_buildpack...
Downloading ruby_buildpack...
Downloading nodejs_buildpack...
Downloading go_buildpack...
Downloaded python_buildpack
Downloaded nodejs_buildpack
Downloaded binary_buildpack
Downloaded php_buildpack
Downloaded go_buildpack
Downloaded go_buildpack_1-6
Downloaded ruby_buildpack
Downloaded java_buildpack_offline
Downloaded null_buildpack
Downloaded staticfile_buildpack
Creating container
Successfully created container
Downloading app package...
Downloaded app package (6.6K)
Staging...
-----> Nothing to do.
**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 (109B)
Uploaded droplet (3.7K)
Uploading complete

0 of 1 instances running, 1 crashed
FAILED
Error restarting application: Start unsuccessful

TIP: use 'cf logs PivotalPushTest --recent' for more information

In Apps Manager Logs:-
OUT Exit status 1
2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**
2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2
2016-09-28T07:05:58.000+00:00 [API] OUT App instance exited with guid
637a95a7-4def-4c43-b00e-454ca6f584f8 payload:
{"instance"=>"460e1817-d616-495e-407e-49991b0026b0", "index"=>0,
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2
error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled",
"crash_count"=>1, "crash_timestamp"=>1475046358426721004,
"version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"}
2016-09-28T07:05:58.000+00:00 [CELL] OUT Creating container
2016-09-28T07:05:58.000+00:00 [CELL] OUT Successfully created
container
2016-09-28T07:05:58.000+00:00 [CELL] OUT Starting health monitoring
of container
2016-09-28T07:05:58.000+00:00 [APP] OUT Exit status 1
2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**
2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2
2016-09-28T07:05:59.000+00:00 [API] OUT App instance exited with guid
637a95a7-4def-4c43-b00e-454ca6f584f8 payload:
{"instance"=>"06f0d873-0050-4e66-6bc8-11ec83ec369f", "index"=>0,
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2
error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled",
"crash_count"=>2, "crash_timestamp"=>1475046358988785723,
"version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"}
2016-09-28T07:05:59.000+00:00 [CELL] OUT Creating container
2016-09-28T07:05:59.000+00:00 [CELL] OUT Successfully created
container
2016-09-28T07:05:59.000+00:00 [CELL] OUT Starting health monitoring
of container
2016-09-28T07:05:59.000+00:00 [APP] OUT Exit status 1
2016-09-28T07:05:59.000+00:00 [APP] ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>
2016-09-28T07:05:59.000+00:00 [CELL] OUT Exit status 2

Please Help,
Mohan V.


Re: JavaBuildpack versioned external configuration

Svetlin Zarev
 

Thanks!


Re: Facing problem while pushing Spring Boot app on PCF

John Feminella <jxf@...>
 

But the null buildpack should never be detected:

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/detect
My reading of this is "the null buildpack is *always* detected". I thought
a buildpack was detected if it returns 0:

https://docs.cloudfoundry.org/buildpacks/custom.html#detect-script

On Wed, Sep 28, 2016, 10:50 Mike Dalessio <mdalessio(a)pivotal.io> wrote:

There's still something weird going on ...

We know that buildpack detection is happening, because we see all the
buildpacks being fetched by Diego in the log.

But the null buildpack should never be detected:

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/detect

Also, it would mean the null buildpack was set as an admin buildpack
(which it wouldn't be by default on PCF) ... it sounds like this CF
installation has been mucked around with from the sane default
configuration.



On Wed, Sep 28, 2016 at 10:33 AM, Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

Disregard what I said earlier. I think John's right. The output from
staging is showing...

Staging...
-----> Nothing to do.
That looks like it could be coming from the null-buildpack.

https://github.com/ryandotsmith/null-buildpack/blob/master/bin/compile

So try specifying `-b java_buildpack_offline` to `cf push` or `buildpack:
java_buildpack_offline` in your manifest.yml. That will force it to use
the JBP. Then see what happens. Like John said, there might be something
off with the JAR file that you also need to fix.

Dan



On Wed, Sep 28, 2016 at 10:01 AM, John Liptak <john.h.liptak(a)gmail.com>
wrote:

I would also specify the java buildpack. If there is a structural
problem in your jar file, the java buildpack may not be detecting it as a
Java application and some other buildpack is attempting to package it.
Generally, spring boot applications and Java buildpacks should have a start
command.

John

On Wed, Sep 28, 2016 at 6:09 AM Daniel Mikusa <dmikusa(a)pivotal.io>
wrote:

What is the system you are targeting? For example, a bosh lite
install, PCF-dev, PWS, Bluemix, other? If it's a system you deployed,
which CF Release & Diego release are you using?

Also, can you push *any* applications to it successfully? Maybe try a
few samples from here [1] and see if any of them work.

2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**

It's this output that has me concerned. You might also want to check
the cell logs to see if there's any additional output on why the launcher
is failing or what arguments it's being given (that it clearly doesn't
like).

Dan

[1] - https://github.com/cloudfoundry-samples/



On Wed, Sep 28, 2016 at 3:44 AM, Mohan V <mohan221213(a)gmail.com> wrote:

I am trying to push the simple spring boot app in pcf.
I am completely new to pcf.
I was created manifest.yml file which contain following data:-

applications:
- name: PivotalPushTest
host: PivotalPushTest
memory: 512M
instances: 1
path:
/root/Desktop/PivotalPushTest/target/PivotalPustTest-0.0.1-SNAPSHOT.jar

but when I am pushing this app via cf push command I am getting
following error:-

cf push
Using manifest file /root/Desktop/PivotalPushTest/manifest.yml

Creating app PivotalPushTest in org ORGNAME / space Java-Hadoop as
username(a)domainname.com...
OK

Using route PivotalPushTest.url.com
Binding PivotalPushTest.url.com to PivotalPushTest...
OK

Uploading PivotalPushTest...
Uploading app files from: /tmp/unzipped-app911037164
Uploading 6.1K, 16 files
Done uploading
OK

Starting app PivotalPushTest in org ORGNAME / space Java-Hadoop as
username(a)domainname.com...
Downloading python_buildpack...
Downloading php_buildpack...
Downloading java_buildpack_offline...
Downloading null_buildpack...
Downloading go_buildpack_1-6...
Downloading staticfile_buildpack...
Downloading binary_buildpack...
Downloading ruby_buildpack...
Downloading nodejs_buildpack...
Downloading go_buildpack...
Downloaded python_buildpack
Downloaded nodejs_buildpack
Downloaded binary_buildpack
Downloaded php_buildpack
Downloaded go_buildpack
Downloaded go_buildpack_1-6
Downloaded ruby_buildpack
Downloaded java_buildpack_offline
Downloaded null_buildpack
Downloaded staticfile_buildpack
Creating container
Successfully created container
Downloading app package...
Downloaded app package (6.6K)
Staging...
-----> Nothing to do.
**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 (109B)
Uploaded droplet (3.7K)
Uploading complete

0 of 1 instances running, 1 crashed
FAILED
Error restarting application: Start unsuccessful

TIP: use 'cf logs PivotalPushTest --recent' for more information

In Apps Manager Logs:-
OUT Exit status 1
2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**
2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2
2016-09-28T07:05:58.000+00:00 [API] OUT App instance exited with guid
637a95a7-4def-4c43-b00e-454ca6f584f8 payload:
{"instance"=>"460e1817-d616-495e-407e-49991b0026b0", "index"=>0,
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2
error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled",
"crash_count"=>1, "crash_timestamp"=>1475046358426721004,
"version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"}
2016-09-28T07:05:58.000+00:00 [CELL] OUT Creating container
2016-09-28T07:05:58.000+00:00 [CELL] OUT Successfully created container
2016-09-28T07:05:58.000+00:00 [CELL] OUT Starting health monitoring of
container
2016-09-28T07:05:58.000+00:00 [APP] OUT Exit status 1
2016-09-28T07:05:58.000+00:00 [APP] **ERR Usage:
/tmp/lifecycle/launcher <app directory> <start command> <metadata>**
2016-09-28T07:05:58.000+00:00 [CELL] OUT Exit status 2
2016-09-28T07:05:59.000+00:00 [API] OUT App instance exited with guid
637a95a7-4def-4c43-b00e-454ca6f584f8 payload:
{"instance"=>"06f0d873-0050-4e66-6bc8-11ec83ec369f", "index"=>0,
"reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* 2
error(s) occurred:\n\n* Exited with status 1\n* cancelled\n* cancelled",
"crash_count"=>2, "crash_timestamp"=>1475046358988785723,
"version"=>"e54e765b-8472-41d5-b14c-eec3f1d41401"}
2016-09-28T07:05:59.000+00:00 [CELL] OUT Creating container
2016-09-28T07:05:59.000+00:00 [CELL] OUT Successfully created container
2016-09-28T07:05:59.000+00:00 [CELL] OUT Starting health monitoring of
container
2016-09-28T07:05:59.000+00:00 [APP] OUT Exit status 1
2016-09-28T07:05:59.000+00:00 [APP] ERR Usage: /tmp/lifecycle/launcher
<app directory> <start command> <metadata>
2016-09-28T07:05:59.000+00:00 [CELL] OUT Exit status 2

Please Help,
Mohan V.


Re: Announcement: default etcd cluster to TLS in cf-release spiff templates

Grifalconi, Michael <michael.grifalconi@...>
 

Hello,

We had the same issue described for almost every upgrade tentative. The best way to summarize the deployments is ‘It works in the end but never at the first try’.

Yes, we have 2 hm9000, 2 loggregator_trafficcontroller and 2 doppler jobs.

Thanks,
Michael.

On 26/09/16 23:57, "Adrian Zankich" <azankich(a)pivotal.io> wrote:

Hi Michael,

Are you still experiencing upgrade issues? Are you deploying multiple instances of the hm9000, loggregator_trafficcontroller and doppler jobs?

- Adrian


Re: FW: issue tracker permissions

Guillaume Berche
 

Thanks Lisa for considering this extra feature to avoid the per-project
invite. I understand an explicit action would still be requested to become
a member of the account owning the CFF projects, for any one willing to
follow, or add projects to workspaces.

The CF community is quite large, so it's possible hundreds of people will
request this. That's be great to have a "request to join owner account"
button, as to avoid wasting time through email requests to the project
owner.

In the meantime until the community gets these self-service accesses, I'll
try maintaining the trackermirror up as a hacky workaround. Please let me
know if ever this causes troubles/inconveniences.

Regards,

Guillaume.

On Thu, Sep 29, 2016 at 9:41 PM, Lisa Doan <ldoan(a)pivotal.io> wrote:

Hi Guillaume,

You need to be invited to be a viewer or member on projects before you can
add them to workspaces. In those screenshots, the only projects appearing
are ones that you are a member or viewer of. In order to have the CF public
projects appear there, you must be invited to the projects.

I understand that it would be burdensome to ask all of the project owners
to invite you to the relevant projects. We are currently working on a
feature that will allow any account member to self-join projects so that
this isn't as difficult. This would require you to become a member of the
account that owns the CF public projects, but once you are a member, you
could join any of the shared or public projects. We expect that to release
later this year (it is part of the body of work that is ahead of Viewers
can follow).

Thanks,
Lisa

On Thu, Sep 29, 2016 at 7:21 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi Lisa,

I double checked, and I still am unable to add public cloudfoundry
tracker projects to my workspaces to be able to search mutiple trackers.
See screenshots below (I'm a reader member of CLI project following kind
invite by Dies Koper). There must be something I got wrong, I'd welcome
help or documentation pointers, and confirmation by other CF community
members that they are able to create such workspaces without being member
of the CF public projects.

Thanks in advance,

Guillaume.

https://www.pivotaltracker.com/n/workspaces/655995

[image: Inline image 1]

[image: Inline image 2]


Guillaume.

On Thu, Sep 29, 2016 at 12:45 AM, Lisa Doan <ldoan(a)pivotal.io> wrote:

Hi Guillaume,

Workspaces can only contain projects that the user is a member OR viewer
of. It is already possible now for a user who is only a viewer of the
public cloudfoundry tracker projects to include those projects in their
workspaces.

Does that answer your question?

Thanks,
Lisa

On Wed, Sep 28, 2016 at 11:45 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Lisa for the additional precisions.

Related to the use of workspaces to search across multiple public
pivotal trackers, I understand a workspace can only contain projects the
logged in user is member of. Is there a possibility that I missed to add
the public cloudfoundry tracker projects (whose non core contributors are
not member of), or would that be a feature enabled along with the upcoming
"viewers can follow" feature ?

Regards,

Guillaume.

On Wed, Sep 28, 2016 at 6:14 PM, Lisa Doan <ldoan(a)pivotal.io> wrote:

Hi Guillaume,

Yes, once Viewers can follow, they'll be able to set notifications
like any project member can. That is, they'll be able to get notifications
on an entire project. Commenting, however, would continue to be restricted
to project members.

Searching across multiple Tracker projects is already possible with
Workspaces
<http://www.pivotaltracker.com/help/articles/managing_multiple_projects_workspaces/>,
but we understand that this feature is limited by not being able to share
workspaces across users. In 2017, we hope to begin building in better
cross-project or portfolio visibility.

Thanks,
Lisa

On Wed, Sep 28, 2016 at 12:00 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Lisa, the "Viewers can follow" feature will be very useful to
the CF community. I plan to redact the GH issue mirrors as to reduce the
confusion caused by implicit cross links between issues that Marco reminded
(see related [a]). When the "Viewers can follow" feature is available,
there will be no more value in discovering GH issues mirrors.

Are there future plans in the tracker to enable viewers to get
notifications for all stories in the backlog ? If not, the promising stack
integration [4], which requires PT project owners to configure the Slack
webhook URL, could help. With collaboration from owners of the Foundation
trackers, this could result into a slack channel per PT project, where
community members can watch related activity, much like what the buildpacks
team have already set up into [b].

The remaining added value for the mirrored GH issues will then be:
- community members "commenting" backlogs in context.
- searching across multiple PT projects

Is the tracker team also planning to address the latter two use-cases
?

Thanks again,

[a] https://github.com/orange-cloudfoundry/pivotaltrackermirror/
issues/1#issuecomment-238706510
[b] https://cloudfoundry.slack.com/messages/buildpacks-firehose/
[4] https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker
"On that page, find the *Activity Web Hook* section. Add
https://hooks.slack.com/services/T02FL4A1X/B2GRZUQ56/zEswA2U
fbCcJl31fCw3DLDq4 as your Web Hook URL. Ensure that the API Version
is set to v5 and then click *Save Web Hook Settings*."

Guillaume.

On Mon, Sep 26, 2016 at 6:26 PM, Lisa Doan <ldoan(a)pivotal.io> wrote:

Hi all -- a couple people reached out asking for a date for Viewers
can follow. We are currently targeting November of this year.

Thanks,
Lisa

On Mon, Sep 26, 2016 at 10:03 AM, Lisa Doan <ldoan(a)pivotal.io>
wrote:

Hi all,

Just to re-iterate, we do have this feature prioritized on the
Tracker team. I'm sorry we haven't been able to deliver this yet, but there
are a number of other higher priority items that we must attend to before
we can begin this work. We will keep you posted as we get closer to
implementing this.

Thanks,
Lisa

On Sun, Sep 25, 2016 at 12:54 AM, Voelz, Marco <marco.voelz(a)sap.com
wrote:
Dear Guillaume,

Thanks for your efforts in this direction. As I already stated
before, it is really a pain that you are not able to follow stories or
comment when not being a member in a Pivotaltracker project. However,
github issues aren’t more than a crutch, probably not even a good one.

For example, GH issues cannot be ordered. They are in the order of
creation, priorization is not visible. Therefore, if you look e.g. at the
BOSH mirror [1], there are a bunch of “unstarted” and “unscheduled” issues,
the first “started” one comes on page 2. For bugs, it gets more confusing.
Most people have the github bot activated, which creates a PT story for
each GH issue created. This is already confusing, because you have two
places where potentially updates to this bug could be located in, and
nobody knows where to look. Add in the mirroring, and now you have three
places, see an example for the buildpacks [2]. All of this is not your
fault, it is a restriction on how GH deals with issues and the fact that
we’re distributing information over more than one place.

While I appreciate your efforts and time spent on this: I strongly
feel that is an issue that can only be solved by one of two options:
• The Pivotaltracker team implementing the necessary functionality
• Migrating to a different tracker

I’m trying all I can to push for the first option by talking to
Dan and Lisa, but other features seem to be more important to the PT team.
In November, it has been a year since I asked for this, so my confidence
isn’t very high that it is going to happen at all. For me that just means
option two is getting more and more realistic every day.

Warm regards
Marco

[1] https://github.com/cf-tm-bot/bosh/issues
[2] https://github.com/cloudfoundry/staticfile-buildpack/issues/85



-----Original Message-----
From: Guillaume Berche <bercheg(a)gmail.com>
Date: Saturday, 24 September 2016 at 12:29
To: "Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
Cc: Chip Childers <cchilders(a)cloudfoundry.org>, "cholick(a)gmail.com"
<cholick(a)gmail.com>, Dan Podsedly <dpodsedly(a)pivotal.io>, Lisa
Doan <ldoan(a)pivotal.io>, "Voelz, Marco" <marco.voelz(a)sap.com>
Subject: Re: [cf-dev] Re: FW: issue tracker permissions

Hi,


The mirroring of foundation projects is around 60% complete.
See [5] for more detailed coverage. This should enable community members to
watch the most active foundation backlogs. I received no notifications of
negative side effects of this mirroring so
far. I'll proceed with mirroring the remaining projects in
the next days/weeks.

There are interesting next steps that could be tackled, such
as enabling commenting on the backlogs, or searching across all foundation
backlog history, see [3]. Let me know if you have interests in discussing
these next steps and current challenges faced by
the mirroring process. The upcoming Frankfurt cfsummit
unconference on monday might be a good place for this, I'd propose a
subject if I receive some interest.


Thanks,


Guillaume.






Guillaume.




On Mon, Sep 5, 2016 at 10:21 PM, Guillaume Berche
<bercheg(a)gmail.com> wrote:

Hi,


We have prototyped at Orange an automatic mirroring of Pivotal
Tracker (PT) stories into github issues. See pivotaltrackermirror at [1],
and the experimental mirror of the buildpack tracker at [2]. I'd like to
thanks the buildpacks team for accepting to join
this experiment and providing us with feedback in the past
few weeks.

We hope this could bring the following benefits to the CF
community:

1. allow use of the
watching notifications <https://help.github.com/artic
les/about-notifications/#types-of-notifications> github feature
to track progress on public pivotal trackers projects: all stories or
selected stories of interest.
2. allow use of
github search features <https://help.github.com/artic
les/searching-github> to search Pivotal Tracker content (e.g.
accross multiple mirrored PT projects, or along with other github
repositories hosting the associated code)
3. allow use of
github @mentions <https://help.github.com/artic
les/basic-writing-and-formatting-syntax/#mentioning-users-an
d-teams> to contact github accounts associated with PT public
projects contributors, in the context with a specific mirrored story
4. mirrored content becomes discoverable: search engines
index it, making it easier to find mirrored PT content such as a stack trace

This is still experimental work. We would like to hear
community feedback about this initiative (how is it useful?), as well as
core contributor teams (are there unexpected side-effects that need to be
handled beyond what we fixed so far [3]?) Do you have
suggestions for enhancements: can you comment/vote/improve in
[3]?


Our plan is to progressively extend this experiment to more
trackers listed in [5] (in a rate of a few projects per week). Please
report issues on [3] if you observe negative side effects, or reply to this
email if you have concerns about this mirroring.



There still a fair amount of work ahead to convert this
experiment into a stable tool, and opportunities to provide some new cool
features to the community. Contributions are welcome :-)



Thanks,


Guillaume.



ps: I also recently noticed a PT slack integration [4] that
would also cover use-case #1 (get notifications for all stories in a
tracker). I'm not yet sure what it takes to add it to a given channel.


[1]
https://github.com/orange-cloudfoundry/pivotaltrackermirror <
https://github.com/orange-cloudfoundry/pivotaltrackermirror>
[2] https://github.com/cf-tm-bot/buildpacks
[3]
https://github.com/orange-cloudfoundry/pivotaltrackermirror/
issues <https://github.com/orange-clo
udfoundry/pivotaltrackermirror/issues>
[4]
https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker
<https://cloudfoundry.slack.com/apps/A0F82E7H8-pivotal-tracker>
[5]
https://github.com/cloudfoundry-community/cf-docs-contrib/wiki
<https://github.com/cloudfoundry-community/cf-docs-contrib/wiki>





Guillaume.




On Sun, May 29, 2016 at 8:05 PM, John Wong
<gokoproject(a)gmail.com> wrote:

Just an idea... Is there a feature in Tracker to always cc
someone/some email address? For non security and non confidential stories
we can Cc this email address automatically which will post to a google
group and a thread will be built as comment is added.
This at least allow a read-only mirror.


Just a thought...


On Sunday, May 29, 2016, Voelz, Marco <marco.voelz(a)sap.com>
wrote:

Dear Dan, dear Lisa, dear Chip, dear community,

sorry for digging out this old issue again and again. If you
are just tuning in, here is the situation
·
I like Pivotal Tracker as a product
·
I have to use Tracker for my daily work, as it is currently
mandatory for all CFF projects and all of them use it
·
The restrictions in pivotal tracker make it hard to impossible
to do the daily stuff you want to do within a large open-source community.

After initially bringing this up in November last year, here
are a few of the problems I addressed with Dan in a hangout session in
February:
·
To follow stories in a project you need to be a member of that
project. Therefore, you cannot track progress on stories in other projects.
·
To comment on stories, the same restrictions as above apply

It has been 3 months since Dan and I talked, I’ve checked back
every 4 weeks with him and what I’ve heard so far is ideas. I haven’t seen
a prototype, any specifics on the current state,
any planning details. It’s not like I’m demanding this
feature should be done by now – I just want to know what is going on.

I have to say I am very unhappy in how this topic is treated.
From my point of view, it seems like there is a huge lack of transparency
and feedback. Please, let me know what’s going on.
I don’t want to switch to a different tracker, such as e.g.
trello, but if the requirements of a large open-source community aren’t
heard, then I don’t know what else to do about this.

Warm regards
Marco

PS: What about a public tracker backlog in tracker, so people
can follow their favorite feature stories and see where they are in the
planning and when they’re done?


On 16/01/16 13:09, "Voelz, Marco" <marco.voelz(a)sap.com> wrote:





Dear all,



it has now been more than a month since I sent my feedback
concerning this feature to the tracker team – I haven't received any
reaction to it.

@Chip:
Is there an option you could weigh in for this from the
Foundation perspective? That would be great!



Sorry for being so stubborn about this, but in my opinion this
is a crucial feature for a bug tracker/backlog which is used in an
open-source product. I know that all the people
working directly at pivotal don't feel the pain, because they
can either talk directly to everyone in person or have the necessary rights
to comment/follow in the other projects, but for everyone else this is
really, really a problem.



Warm regards

Marco



On 09/12/15 21:20, "Voelz, Marco" <marco.voelz(a)sap.com> wrote:




Thanks for pointing me to this link. However, we seem to have
the same problem here: This seems like a fire-and-forget solution. Where
does this item go? How can I send it to
other people and have them +1 it, like it, follow it,
favorite it or whatever is necessary to indicate that there is more than 1
person wanting this feature?




Thanks and warm regards

Marco



On 09/12/15 20:01, "Amit Gupta" <agupta(a)pivotal.io> wrote:




If you're logged in to Tracker, there's a "Help & Updates"
link at the top, and one of the options is Provide Feedback.


On Wed, Dec 9, 2015 at 10:59 AM, Voelz, Marco <
marco.voelz(a)sap.com> wrote:

I'd happily submit a feature request to build up some visible
demand for this – could you point me to the right channel here?




Thanks and warm regards

Marco



On 08/12/15 23:01, "Dieu Cao" <dcao(a)pivotal.io> wrote:





Unfortunately in order to follow a story in tracker, the
minimum required level is "member" which allows you to
create/comment/delete stories in tracker.

I would suggest submitting a request to the pivotal tracker
team to help build up evidence that this is a feature that people want.



-Dieu



On Tue, Dec 8, 2015 at 12:49 PM, Matt Cholick <
cholick(a)gmail.com> wrote:

Sorry to resurrect an older thread, but I wanted to chime in
that this is a frustration I have too. There are several stories in the
various CF teams public backlogs that I'd
like to keep track of.


Is it possible for community members to get enough permissions
on our tracker accounts to add ourselves to the follow list?



-Matt



On Mon, Nov 23, 2015 at 3:10 AM, Koper, Dies <
diesk(a)fast.au.fujitsu.com> wrote:

Hi Marco, Jan,

I sent an email to Tracker support about that last week
because we were hoping to close CLI feature requests on GH and let people
follow the stories on Tracker. Support confirmed that people need to have
R/W access to a project to do that.
I have just replied to ask if they'd consider an enhancement.
Not sure what the proper channel would be to get such a story prioritized.
Will let you know if I get a reply.

Regards,
Dies Koper
Cloud Foundry CLI PM

-----Original Message-----
From: Voelz, Marco [mailto:marco.voelz(a)sap.com]
Sent: Monday, November 23, 2015 8:00 PM
To: Discussions about Cloud Foundry projects and the system
overall.
Subject: [cf-dev] Re: FW: issue tracker permissions

Thanks Jan for bringing that up, I've had similar problems
with that as well. Any ideas on how to solve this? Is this a feature that
the tracker team actively works on?
Hitting cmd+r every few days on the same stories doesn't seem
like the best way to stay informed about your favorite features.

Warm regards
Marco



On 19/11/15 09:23, "Sievers, Jan" <jan.sievers(a)sap.com> wrote:

>>Hi,
>>
>>I was trying to watch a story I am interested in
>>https://www.pivotaltracker.com/n/projects/892938/stories/1
05493826
>>
>>
>>I do have an account but it seems I don't have permissions
to watch nor to comment.
>>
>>Is there something I missed?
>>
>>Regards
>>Jan
>>





































































--
Sent from Jeff Dean's printf() mobile console















[security] CVE-2016-6653: MySQL Audit logs sent to Syslog

Travis McPeak
 

Severity

High
Vendor

Cloud Foundry Foundation
Versions Affected

-

Cloud Foundry MySQL Release versions 27[1] and 28[2]

Description

MariaDB’s audit_plugin, incorporated in cf-mysql-release starting with
cf-mysql-release v27, allows the Operator to enable audit trails, which log
all queries sent to the SQL server. With the incorporation of this plugin,
a bug was introduced that causes those logs to be sent to syslog. Depending
on the nature of the applications that use cf-mysql, these audit logs may
contain Personally Identifiable Information (PII) of application users,
including unencrypted application access credentials and any
application-specific data written to the database.

The audit_plugin automatically redacts credentials in MySQL user creation.
MySQL server access credentials are not sent to syslog.

Note: The property, cf_mysql.mysql.server_audit_events, which enables Audit
logging is not enabled by default in the release’s spec file
<https://github.com/cloudfoundry/cf-mysql-release/blob/v27/jobs/mysql/spec#L104>.
The audit feature must have been manually enabled by an Operator before
deploying.
Mitigation

OSS users are strongly encouraged to follow one of the mitigations below:

-

Deploy cf-mysql-release v29
-

Disable audit logging by deleting the values of
cf_mysql.mysql.server_audit_events and re-deploying.
-

Decide how to best handle audit log records that have been stored by
your syslog server (implementation varies).


Examples

Below are several examples of audit log events as they will appear in
syslog. Scan for entries like these in order to validate that you are no
longer sending audit logs to syslog.

20160926 19:55:49,9da585c7-1abc-1234-a6b2-7ee157f6ba65,root,192.0.2.
11,118512,16585118,QUERY,mysql_broker,'CREATE USER \'zconN9KAQ6PwXsQC\'
IDENTIFIED BY *****',0

20160926 22:33:02,d27a463f-x123-1234-96f4-d0ce7b6b298e,EN0wrPpthGzaC7
pU,192.0.2.11,120867,29195687,QUERY,cf_fa403c9e_1234_1234_ad0a_70d53d277dbc,'SELECT
`partition_spec`.* FROM `partition_spec` WHERE `partition_spec`.`name` =
\'ordered\' LIMIT 1',0

20160926 22:33:02,d27a463f-x123-1234-96f4-d0ce7b6b298e,dX3qqBoWRGJGZo
Px,192.0.2.11,444,29195516,QUERY,cf_da07adfc_123x_1234_a934_dae104226a95,'SELECT
`daemon`.* FROM `daemon` WHERE `daemon`.`name` =
\'ordered_delayed_job_workers\' LIMIT 1',0

Credit

This issue was discovered by the Cloud Foundry cf-mysql development team.
References

-

[1] https://github.com/cloudfoundry/cf-mysql-release/releases/v27
-

[2] https://github.com/cloudfoundry/cf-mysql-release/releases/v28


Re: JavaBuildpack versioned external configuration

Ben Hale <bhale@...>
 

And the following env variable: JBP_CONFIG_TOMCAT: "{ tomcat: { external_configuration_enabled: true }, external_configuration: { repository_root: \" https://repository.example.org/\" } }"

Then is there a way to tell the buildpack to pick 1.0.0 or 1.1.0 ? Is there something like specifying { version: 1.0.0 } in the env variable ?
The environment variable configuration is a “flow” style[1] YAML representation of the configuration file[2] being configured. If you review the documentation for the Tomcat configuration[3], you’ll see that there is a `external_configuration.version` property to go along with the `external_configuration.repository_root` property.

-V



[1]: http://www.yaml.org/spec/1.2/spec.html#Flow
[2]: https://github.com/cloudfoundry/java-buildpack/blob/master/config/tomcat.yml#L23
[3]: https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-tomcat.md#configuration

3621 - 3640 of 9429