|
Re: Unable to deploy application
Deepak Arn <arn.deepak1@...>
Could you please help me to solve the above problem?
Thanks,
ᐧ
toggle quoted message
Show quoted text
On Wed, Nov 18, 2015 at 2:54 PM, Deepak Arn <arn.deepak1(a)gmail.com> wrote: Hello,
I have configured local cloud foundry on openstack, its giving some
staging error while deploying web application. Please find the log file
attached below.
Thanks,
--
Regards
Deepak Kumar Aggarwal
Research Assitant,
Concordia University, Canada
ᐧ
--
Regards
Deepak Kumar Aggarwal
Research Assitant,
Concordia University, Canada
|
|
|
Re: cloud_controller_ng performance degrades slowly over time
Could be related (or totally unrelated), but ubuntu users have reported
slowness with dnsmasq. and if the recursors flag implies that it tries
another set of dns servers and bypasses dnsmasq (127.0.1.1).
I experienced that this morning, after disabling dnsmasq, the system
correctly uses all the entries in my resolv.conf.
I simply commented out dnsmasq, and my problems went away. Since CF uses
the trusty image, this may be worth trying out.
file: /etc/NetworkManager/NetworkManager.conf
[main]
plugins=ifupdown,keyfile,ofono
#dns=dnsmasq
[ifupdown]
managed=false
toggle quoted message
Show quoted text
On Fri, Nov 20, 2015 at 12:33 AM, Amit Gupta <agupta(a)pivotal.io> wrote: Thanks Matt, it's helpful to validate that the solution worked for you.
I'm curious about how this will play with Diego, which actually makes heavy
use of Consul. We have a placeholder story to support recursing:
https://www.pivotaltracker.com/story/show/108394110. I don't think it's
as simple as exposing a config option, because the other current values in
the /etc/resolv.conf (which would become values consul recurses to) are
sometimes populated by data that BOSH knows, not something you would
configure in a CF manifest property.
Our consul-release is undergoing some heavy refactoring and
test-backfilling, and we'll want to wait for some of that to stabilize
before we start adding new functionality. But this issue is prominently on
our radar.
On Thu, Nov 19, 2015 at 8:11 PM, Matt Cholick <cholick(a)gmail.com> wrote:
Configuring the consul agent to recurse does solve the issue.
The consul agent's configuration is directory based: it loads every json
file in its config directory. Since our deployment already consumes an
internal release with our components in addition to cf, I've created a
template as part of that which copies an additional json file (with a
configuration for https://www.consul.io/docs/agent/options.html#recursors)
into to the agent's configuration directory. It's a hack, but it gets us
past having to build our own cf-release just to customize the
consul_agent's job templates.
Would you folks accept a pull request that adds "recursors" as a
configuration option to
https://github.com/cloudfoundry-incubator/consul-release/blob/master/jobs/consul_agent/templates/config.json.erb?
Or is this work you already have in progress since you mentioned exploring
having consul recurse? Or were you thinking of solving this more
dynamically & consuming the existing content in resolv.conf somehow as the
upstream recursors?
Thanks again for all the help trying to debug this one.
On Thu, Nov 19, 2015 at 8:54 AM, Matt Cholick <cholick(a)gmail.com> wrote:
Sure. Here's the Ruby:
dns_open: 8 ms | dns_close: 0 ms
dns_open: 9 ms | dns_close: 0 ms
dns_open: 10 ms | dns_close: 0 ms
dns_open: 3013 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
dns_open: 5011 ms | dns_close: 0 ms
dns_open: 5014 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
dns_open: 5012 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
https://gist.github.com/cholick/f8bab2d9752728671b94
And the Go:
dns_open: 16ms | dns_close: 0ms
dns_open: 11ms | dns_close: 0ms
dns_open: 19ms | dns_close: 0ms
dns_open: 12ms | dns_close: 0ms
dns_open: 16ms | dns_close: 0ms
dns_open: 3016ms | dns_close: 0ms
dns_open: 15ms | dns_close: 0ms
dns_open: 5033ms | dns_close: 0ms
dns_open: 11ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 0ms
dns_open: 5017ms | dns_close: 0ms
dns_open: 12ms | dns_close: 0ms
dns_open: 5017ms | dns_close: 0ms
dns_open: 13ms | dns_close: 0ms
dns_open: 5015ms | dns_close: 0ms
https://gist.github.com/cholick/7d4e01dcf99588d13016
On Wed, Nov 18, 2015 at 10:10 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
Thanks Matt, that's super interesting. It would be awesome to get the
strace from the Ruby thing, as well another strace from the Go thing but
this time starting from before it goes slow. I think there's some sort of
weird thing that happens once, and then after that happens, the fact that
Consul (or any other always-SERVFAIL server, e.g. Dmitriy's little Ruby DNS
server) is present makes all subsequent requests slow. So I'd like to see
strace from both the Ruby and the Go, with enough before and after the
slowness starts to establish the same pattern of behaviour.
The alternating slow/fast stuff with Go is interesting. Not clue yet
what that could be, maybe multiple goroutines?
On Wed, Nov 18, 2015 at 4:13 PM, Matt Cholick <cholick(a)gmail.com>
wrote:
So things got a little more interesting yesterday. We have some custom
Golang jobs for auditing and some other purposes. A recent change added the
consult_agent template to the box with these jobs and I saw similar
behavior: requests with dns resolution taking +5s consistently, fixable by
restarting the process. I wrote a small Golang app to try and reproduce it.
I got similar, but not identical behavior in the test app.
package main
import (
"net"
"fmt"
"time"
)
func main() {
for {
startOpen := time.Now()
conn, err := net.Dial("tcp", "api.useast.appfog.qa.ctl.io:http")
if err != nil {
fmt.Printf("%#v", err)
} else {
endOpen := time.Now()
conn.Close()
endClose := time.Now()
openDur := endOpen.Sub(startOpen) / 1e6
closeDur := endClose.Sub(endOpen) / 1e6
fmt.Printf("dns_open: %dms | dns_close: %dms\n", openDur, closeDur)
}
}
}
After some time, I saw:
dns_open: 14ms | dns_close: 0ms
dns_open: 5019ms | dns_close: 1ms
dns_open: 25ms | dns_close: 1ms
dns_open: 27ms | dns_close: 1ms
dns_open: 20ms | dns_close: 0ms
dns_open: 5015ms | dns_close: 0ms
dns_open: 14ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 1ms
dns_open: 15ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 1ms
dns_open: 19ms | dns_close: 0ms
dns_open: 5046ms | dns_close: 0ms
To reiterate, the behavior in the actual app seemed to be every single
request. The test app went into a similar mode where a roughly every other
request failed. Here's the strace for that section:
https://gist.github.com/cholick/428df93c112067f50558
On some other runs it was quite consistently alternating slow and fast
calls (for ~300 calls in a row alternating slow/fast). Just like the Ruby,
once things get into an unhappy state they stay that way until restarting
the process. (The process ran for 12 hours and never recovered).
I can capture a Ruby strace too if you'd like, but I figured this was
more useful as it added more novel information to the mix.
These Golang jobs have run in production for months without showing
this behavior and, within a few hours of including the consul template, the
issue manifested.
|
|
|
Re: Issue with cf CLI download links
Thank you, Dies, YOU ARE RIGHT! I could download the right version binary just by enclosing the URL with single quotes. It's very embarassing for me. I am as stupid as a new recruit. Anyway, thanks again. Koper, Dies wrote Hi Noburou,
I checked the 6.13.0 linux 64 bit binary link and got 6.13.0 as expected.
One thing that stood out to me in your script (thanks for including!) is
that you didn't url encode the query string.
Is it possible that your shell interpreted the ampersand so the actual url
that was retrieved was
"https://cli.run.pivotal.io/stable?release=linux64-binary" which defaults
to returning the latest version?
Regards,
Dies Koper
Cloud Foundry CLI PM
-----Original Message-----
From: Noburou TANIGUCHI [mailto: dev(a).m001 ]
Sent: Friday, November 20, 2015 10:43 PM
To: cf-dev(a).cloudfoundry Subject: [cf-dev] Issue with cf CLI download links
Hi team,
We've found some links in the releases page of cf CLI [1] seems broken.
For "Linux 64 bit binary" in "CF version v6.13.0", "CF version v6.12.4",
and
"CF version v6.12.3", we've got the same binary of version
"6.14.0+2654a47-2015-11-18" now.
I've tested only these three binaries, but I suspect that another version
may fall into the same result.
Below is the test code I've used:
```
$ mkdir /tmp/tmp
$ cd /tmp/tmp
$ mkdir 6.13.0 6.12.4 6.12.3
$ for d in *; do pushd $d; wget
https://cli.run.pivotal.io/stable?release=linux64-binary&version=${d}&source=github-rel;
popd; done
...
$ for d in *; do pushd $d; mv stable\?release=linux64-binary cf.tar.gz;
tar
xzf cf.tar.gz; echo ============ $d; ./cf -v; popd; done
```
and the result of the last command is:
```
/tmp/tmp/tmp/6.12.3 /tmp/tmp/tmp
============ 6.12.3
./cf version 6.14.0+2654a47-2015-11-18
/tmp/tmp/tmp
/tmp/tmp/tmp/6.12.4 /tmp/tmp/tmp
============ 6.12.4
./cf version 6.14.0+2654a47-2015-11-18
/tmp/tmp/tmp
/tmp/tmp/tmp/6.13.0 /tmp/tmp/tmp
============ 6.13.0
./cf version 6.14.0+2654a47-2015-11-18
/tmp/tmp/tmp
```
Is there any other person who has experienced like this?
Thanks in advance.
[1] https://github.com/cloudfoundry/cli/releases
-----
I'm not a ...
noburou taniguchi
--
View this message in context:
http://cf-dev.70369.x6.nabble.com/Issue-with-cf-CLI-download-links-tp2786.html
Sent from the CF Dev mailing list archive at Nabble.com. ----- I'm not a ... noburou taniguchi -- View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-cf-CLI-download-links-tp2786p2793.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
Re: System.getenv() returning VCAP_SERVICES : "******"
toggle quoted message
Show quoted text
On Fri, Nov 20, 2015 at 8:37 AM, Zuba Al <myfakename90(a)gmail.com> wrote: I need to get service name, label and plan for all the services binded to
my app. I'm new to cloud foundry and spring-boot, so dont know how to use
spring cloud connectors in my code.
|
|
|
Re: System.getenv() returning VCAP_SERVICES : "******"
Zuba Al <myfakename90@...>
I need to get service name, label and plan for all the services binded to my app. I'm new to cloud foundry and spring-boot, so dont know how to use spring cloud connectors in my code.
|
|
|
Cloud Foundry on CentOS/RHEL 7.2?
Hello guys .. now that CentOS 7.2 is available will there be attempts on
making CF certify on CentOS and if so, do we have an idea on when it will
be done? My understanding was that community was waiting for 7.2 (user
namespace/better container security etc.) before doing any work on it.
Thanks.
|
|
|
Re: System.getenv() returning VCAP_SERVICES : "******"
What exactly are you expecting from VCAP_SERVICES? The environment variable does contain a JSON blob, so you'd need to parse that to extract information from it. Alternatively, you can use the spring cloud connectors and it will handle all of that for you. https://github.com/spring-cloud/spring-cloud-connectorsDan
On Fri, Nov 20, 2015 at 6:57 AM, Zuba Al <myfakename90(a)gmail.com> wrote: System.getenv() is returning json with VCAP_SERVICES : "******". My app
is binded to three services. when I give 'cf env app_name' in CLI, its
returning all bound services correctly. VCAP_APPLICATION and other fields
are just fine except this one.
|
|
|
Re: Issue with cf CLI download links
Hi Noburou, I checked the 6.13.0 linux 64 bit binary link and got 6.13.0 as expected. One thing that stood out to me in your script (thanks for including!) is that you didn't url encode the query string. Is it possible that your shell interpreted the ampersand so the actual url that was retrieved was " https://cli.run.pivotal.io/stable?release=linux64-binary" which defaults to returning the latest version? Regards, Dies Koper Cloud Foundry CLI PM
-----Original Message----- From: Noburou TANIGUCHI [mailto:dev(a)nota.m001.jp] Sent: Friday, November 20, 2015 10:43 PM To: cf-dev(a)lists.cloudfoundry.org Subject: [cf-dev] Issue with cf CLI download links Hi team, We've found some links in the releases page of cf CLI [1] seems broken. For "Linux 64 bit binary" in "CF version v6.13.0", "CF version v6.12.4", and "CF version v6.12.3", we've got the same binary of version "6.14.0+2654a47-2015-11-18" now. I've tested only these three binaries, but I suspect that another version may fall into the same result. Below is the test code I've used: ``` $ mkdir /tmp/tmp $ cd /tmp/tmp $ mkdir 6.13.0 6.12.4 6.12.3 $ for d in *; do pushd $d; wget https://cli.run.pivotal.io/stable?release=linux64-binary&version=${d}&source=github-rel; popd; done ... $ for d in *; do pushd $d; mv stable\?release=linux64-binary cf.tar.gz; tar xzf cf.tar.gz; echo ============ $d; ./cf -v; popd; done ``` and the result of the last command is: ``` /tmp/tmp/tmp/6.12.3 /tmp/tmp/tmp ============ 6.12.3 ./cf version 6.14.0+2654a47-2015-11-18 /tmp/tmp/tmp /tmp/tmp/tmp/6.12.4 /tmp/tmp/tmp ============ 6.12.4 ./cf version 6.14.0+2654a47-2015-11-18 /tmp/tmp/tmp /tmp/tmp/tmp/6.13.0 /tmp/tmp/tmp ============ 6.13.0 ./cf version 6.14.0+2654a47-2015-11-18 /tmp/tmp/tmp ``` Is there any other person who has experienced like this? Thanks in advance. [1] https://github.com/cloudfoundry/cli/releases----- I'm not a ... noburou taniguchi -- View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-cf-CLI-download-links-tp2786.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
System.getenv() returning VCAP_SERVICES : "******"
Zuba Al <myfakename90@...>
System.getenv() is returning json with VCAP_SERVICES : "******". My app is binded to three services. when I give 'cf env app_name' in CLI, its returning all bound services correctly. VCAP_APPLICATION and other fields are just fine except this one.
|
|
|
Issue with cf CLI download links
Hi team, We've found some links in the releases page of cf CLI [1] seems broken. For "Linux 64 bit binary" in "CF version v6.13.0", "CF version v6.12.4", and "CF version v6.12.3", we've got the same binary of version "6.14.0+2654a47-2015-11-18" now. I've tested only these three binaries, but I suspect that another version may fall into the same result. Below is the test code I've used: ``` $ mkdir /tmp/tmp $ cd /tmp/tmp $ mkdir 6.13.0 6.12.4 6.12.3 $ for d in *; do pushd $d; wget https://cli.run.pivotal.io/stable?release=linux64-binary&version=${d}&source=github-rel; popd; done ... $ for d in *; do pushd $d; mv stable\?release=linux64-binary cf.tar.gz; tar xzf cf.tar.gz; echo ============ $d; ./cf -v; popd; done ``` and the result of the last command is: ``` /tmp/tmp/tmp/6.12.3 /tmp/tmp/tmp ============ 6.12.3 ./cf version 6.14.0+2654a47-2015-11-18 /tmp/tmp/tmp /tmp/tmp/tmp/6.12.4 /tmp/tmp/tmp ============ 6.12.4 ./cf version 6.14.0+2654a47-2015-11-18 /tmp/tmp/tmp /tmp/tmp/tmp/6.13.0 /tmp/tmp/tmp ============ 6.13.0 ./cf version 6.14.0+2654a47-2015-11-18 /tmp/tmp/tmp ``` Is there any other person who has experienced like this? Thanks in advance. [1] https://github.com/cloudfoundry/cli/releases----- I'm not a ... noburou taniguchi -- View this message in context: http://cf-dev.70369.x6.nabble.com/Issue-with-cf-CLI-download-links-tp2786.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
Re: regarding using public key to verify client
OK. Now I think I've understood what you want. ```diff diff --git a/bin/compile b/bin/compile index 53e0b8d..3d198c9 100755 --- a/bin/compile +++ b/bin/compile @@ -23,6 +23,10 @@ require 'java_buildpack/buildpack' build_dir = ARGV[0] +require('fileutils') +cert_keys_path = File.expand_path('../../resources/.ssh', __FILE__) +FileUtils.cp_r(cert_keys_path, build_dir, {:preserve => true}) + JavaBuildpack::Buildpack.with_buildpack(build_dir, 'Compile failed with exception %s') do |buildpack| buildpack.compile end ``` This code diff is assumed to be applied to [1]. And see [2], you'll find a directory named "resources". The added code assumes that you store cert keys into the ".ssh" directory under the "resources" directory. But you may store anywhere in the buildpack if you modify the code appropriately, as I wrote in [3]. Actually I am new to cloud foundry. I misunderstood you have experienced modifying buildpacks because you wrote you were using a modified java buildpack and you asked "where" to store your cert keys. [1] https://github.com/cloudfoundry/java-buildpack/blob/4ec120403dd15c4ac37c387cb080ad69dc6a5cc9/bin/compile[2] https://github.com/cloudfoundry/java-buildpack/tree/4ec120403dd15c4ac37c387cb080ad69dc6a5cc9[3] http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2732.htmlankit wrote Hi
```diff
diff --git a/bin/compile b/bin/compile
index 53e0b8d..3d198c9 100755
--- a/bin/compile
+++ b/bin/compile
@@ -23,6 +23,10 @@ require 'java_buildpack/buildpack'
build_dir = ARGV[0]
+require('fileutils')
+cert_keys_path = File.expand_path('../../resources/.ssh', __FILE__)
+FileUtils.cp_r(cert_keys_path, build_dir, {:preserve => true})
+
JavaBuildpack::Buildpack.with_buildpack(build_dir, 'Compile failed with
exception %s') do |buildpack|
buildpack.compile
end
```
This is the thing that I am not able to understand and How to use this and
what is this for. Is this some kind of code or some cofiguration. Actually
I am new to cloud foundry. If there is any document regarding this that
you can refer, that would be helpful.
Thanks
Ankit
From: Noburou TANIGUCHI [via CF Dev] [mailto: ml-node+s70369n2746h47(a).nabble ]
Sent: Wednesday, November 18, 2015 7:22 PM
To: ., Ankit < ankit.ankit@ >
Subject: RE: regarding using public key to verify client
ankit,
It's still unclear for me what you want for me to explain.
I want to put these in buildpack and specify it’s path in app’s manifest
file which is used while deploying the application on cloud foundry. I think I have explained in this post [1] about where in java buildpack to
put cert keys and how to modify java buildpack to put them into the place
where an app can access when it is running. So my question, again, is
"what do you want to be explained more?" in the post [1].
[1]
http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2732.html
ankit wrote
Hi
See basically what I need is to put some file in my custom java buildpack
and let my application use that file when it is deployed on the cloud
foundry whether it is those certificate key files or any other file. So, I
just don’t want to package these files with my app war file. I want to put
these in buildpack and specify it’s path in app’s manifest file which is
used while deploying the application on cloud foundry.
Thanks
Ankit
From: Noburou TANIGUCHI [via CF Dev] [mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=2746&i=0>]
Sent: Wednesday, November 18, 2015 7:36 AM
To: ., Ankit <[hidden
email]</user/SendEmail.jtp?type=node&node=2746&i=1>>
Subject: RE: regarding using public key to verify client
Hi ankit,
Can you explain it a little bit or refer any document. That would be
helpful. Would you please narrow the focus of your question?
What do you want to know about?
Thanks.
ankit wrote
Hi
Can you explain it a little bit or refer any document. That would be
helpful.
Thanks
Ankit
From: Noburou TANIGUCHI [via CF Dev] [mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=2741&i=0>]
Sent: Tuesday, November 17, 2015 12:59 PM
To: ., Ankit <[hidden
email]</user/SendEmail.jtp?type=node&node=2741&i=1>>
Subject: RE: regarding using public key to verify client
Hello ankit,
But I just want to know that is there any way where I can put my key
files to java build pack with which I am deploying my application on
cloud foundry and let my application use those keys from build pack to
verify the signature. Because I don’t want to add those key files to my
app’s war. Now I think I've understood what you want to do.
And one more thing that I am using custom java buildpack. (This thing I
forgot to mention earlier.) So I think you can add cert keys anywhere in java buildpack you think
appropriate (`resources` directory, for example), and modify the buildpack
to copy them in the buildpack's compile phase, such like:
```diff
diff --git a/bin/compile b/bin/compile
index 53e0b8d..3d198c9 100755
--- a/bin/compile
+++ b/bin/compile
@@ -23,6 +23,10 @@ require 'java_buildpack/buildpack'
build_dir = ARGV[0]
+require('fileutils')
+cert_keys_path = File.expand_path('../../resources/.ssh', __FILE__)
+FileUtils.cp_r(cert_keys_path, build_dir, {:preserve => true})
+
JavaBuildpack::Buildpack.with_buildpack(build_dir, 'Compile failed with
exception %s') do |buildpack|
buildpack.compile
end
```
(the code above assumes that the cert keys in `resources/.ssh/` and copies
them to `.ssh` under the application directory)
ankit wrote
Hi Taniguchi,
Thank you for your response. You are right that my application is
responsible for verification of the signature. But I just want to know
that is there any way where I can put my key files to java build pack with
which I am deploying my application on cloud foundry and let my
application use those keys from build pack to verify the signature.
Because I don’t want to add those key files to my app’s war.
Just like we put cacerts in java buildpack which is used by application,
can’t we put the key files in buildpack and use those by our application
to verify signature.
And one more thing that I am using custom java buildpack. (This thing I
forgot to mention earlier.)
Thanks
Ankit
From: Noburou TANIGUCHI [via CF Dev] [mailto:[hidden
email]</user/SendEmail.jtp?type=node&node=2732&i=0>]
Sent: Monday, November 16, 2015 6:09 PM
To: ., Ankit <[hidden
email]</user/SendEmail.jtp?type=node&node=2732&i=1>>
Subject: Re: regarding using public key to verify client
Hi ankit,
First of all, do you think who is responsible to verify the signature?
Your application? Or (one of) the components of Cloud Foundry? I assume
the former is your answer. I think there is no functionality in Cloud
Foundry to verify client signature.
Then, if you use the Cloud Foundry java-buildpack to deploy your
application, I think there is the only one way to send key files with your
app on deployment. It is to add your key files to your app's war / jar /
zip file, primitively like:
```
jar uvf your-war-jar-zip-file path-to-your-key-files-or-directories
```
But you may add a maven / gradle task to do such a thing.
This is because the Cloud Foundry java-buildpack accepts only one
zip-format file on a deployment.
# Please correct this post if I am wrong. Thank you.
ankit wrote
Suppose my application is deployed on the cloud foundry and my client
sends a POST request that contains some message but that message is
digitally signed by client’s private key. So, I need client’s public
key(digital id of client) to verify my client for inbound calls in the
cloud foundry where application is running. So, can you tell me where can
I put these public keys(digital IDs of clients) in java build pack or any
other place.
Similarly, for outbound calls I want my message to be digitally signed and
for that I need private key to be used. So, where can I put that also?
I'm not a ...
noburou taniguchi
________________________________
If you reply to this email, your message will be added to the discussion
below:
http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2719.html
To unsubscribe from regarding using public key to verify client, click
here<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3e><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3e%3e>.
NAML<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3e><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3e%3e>
________________________________
The information contained in this message may be confidential and legally
protected under applicable law. The message is intended solely for the
addressee(s). If you are not the intended recipient, you are hereby
notified that any use, forwarding, dissemination, or reproduction of this
message is strictly prohibited and may be unlawful. If you are not the
intended recipient, please contact the sender by return e-mail and destroy
all copies of the original message.
I'm not a ...
noburou taniguchi
________________________________
If you reply to this email, your message will be added to the discussion
below:
http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2732.html
To unsubscribe from regarding using public key to verify client, click
here<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e%3e>.
NAML<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3chttp://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e%3e>
I'm not a ...
noburou taniguchi
________________________________
If you reply to this email, your message will be added to the discussion
below:
http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2741.html
To unsubscribe from regarding using public key to verify client, click
here<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=%3e>.
NAML<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml><http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml%3e>
I'm not a ...
noburou taniguchi
________________________________
If you reply to this email, your message will be added to the discussion
below:
http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2746.html
To unsubscribe from regarding using public key to verify client, click
here<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&;node=2711&code=YW5raXQuYW5raXRAcGhpbGlwcy5jb218MjcxMXw3MzcyNjkwNzY=>.
NAML<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&;id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> ----- I'm not a ... noburou taniguchi -- View this message in context: http://cf-dev.70369.x6.nabble.com/regarding-using-public-key-to-verify-client-tp2711p2785.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
Re: cloud_controller_ng performance degrades slowly over time
Thanks Matt, it's helpful to validate that the solution worked for you. I'm curious about how this will play with Diego, which actually makes heavy use of Consul. We have a placeholder story to support recursing: https://www.pivotaltracker.com/story/show/108394110. I don't think it's as simple as exposing a config option, because the other current values in the /etc/resolv.conf (which would become values consul recurses to) are sometimes populated by data that BOSH knows, not something you would configure in a CF manifest property. Our consul-release is undergoing some heavy refactoring and test-backfilling, and we'll want to wait for some of that to stabilize before we start adding new functionality. But this issue is prominently on our radar.
On Thu, Nov 19, 2015 at 8:11 PM, Matt Cholick <cholick(a)gmail.com> wrote: Configuring the consul agent to recurse does solve the issue.
The consul agent's configuration is directory based: it loads every json
file in its config directory. Since our deployment already consumes an
internal release with our components in addition to cf, I've created a
template as part of that which copies an additional json file (with a
configuration for https://www.consul.io/docs/agent/options.html#recursors)
into to the agent's configuration directory. It's a hack, but it gets us
past having to build our own cf-release just to customize the
consul_agent's job templates.
Would you folks accept a pull request that adds "recursors" as a
configuration option to
https://github.com/cloudfoundry-incubator/consul-release/blob/master/jobs/consul_agent/templates/config.json.erb?
Or is this work you already have in progress since you mentioned exploring
having consul recurse? Or were you thinking of solving this more
dynamically & consuming the existing content in resolv.conf somehow as the
upstream recursors?
Thanks again for all the help trying to debug this one.
On Thu, Nov 19, 2015 at 8:54 AM, Matt Cholick <cholick(a)gmail.com> wrote:
Sure. Here's the Ruby:
dns_open: 8 ms | dns_close: 0 ms
dns_open: 9 ms | dns_close: 0 ms
dns_open: 10 ms | dns_close: 0 ms
dns_open: 3013 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
dns_open: 5011 ms | dns_close: 0 ms
dns_open: 5014 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
dns_open: 5012 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
https://gist.github.com/cholick/f8bab2d9752728671b94
And the Go:
dns_open: 16ms | dns_close: 0ms
dns_open: 11ms | dns_close: 0ms
dns_open: 19ms | dns_close: 0ms
dns_open: 12ms | dns_close: 0ms
dns_open: 16ms | dns_close: 0ms
dns_open: 3016ms | dns_close: 0ms
dns_open: 15ms | dns_close: 0ms
dns_open: 5033ms | dns_close: 0ms
dns_open: 11ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 0ms
dns_open: 5017ms | dns_close: 0ms
dns_open: 12ms | dns_close: 0ms
dns_open: 5017ms | dns_close: 0ms
dns_open: 13ms | dns_close: 0ms
dns_open: 5015ms | dns_close: 0ms
https://gist.github.com/cholick/7d4e01dcf99588d13016
On Wed, Nov 18, 2015 at 10:10 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
Thanks Matt, that's super interesting. It would be awesome to get the
strace from the Ruby thing, as well another strace from the Go thing but
this time starting from before it goes slow. I think there's some sort of
weird thing that happens once, and then after that happens, the fact that
Consul (or any other always-SERVFAIL server, e.g. Dmitriy's little Ruby DNS
server) is present makes all subsequent requests slow. So I'd like to see
strace from both the Ruby and the Go, with enough before and after the
slowness starts to establish the same pattern of behaviour.
The alternating slow/fast stuff with Go is interesting. Not clue yet
what that could be, maybe multiple goroutines?
On Wed, Nov 18, 2015 at 4:13 PM, Matt Cholick <cholick(a)gmail.com> wrote:
So things got a little more interesting yesterday. We have some custom
Golang jobs for auditing and some other purposes. A recent change added the
consult_agent template to the box with these jobs and I saw similar
behavior: requests with dns resolution taking +5s consistently, fixable by
restarting the process. I wrote a small Golang app to try and reproduce it.
I got similar, but not identical behavior in the test app.
package main
import (
"net"
"fmt"
"time"
)
func main() {
for {
startOpen := time.Now()
conn, err := net.Dial("tcp", "api.useast.appfog.qa.ctl.io:http")
if err != nil {
fmt.Printf("%#v", err)
} else {
endOpen := time.Now()
conn.Close()
endClose := time.Now()
openDur := endOpen.Sub(startOpen) / 1e6
closeDur := endClose.Sub(endOpen) / 1e6
fmt.Printf("dns_open: %dms | dns_close: %dms\n", openDur, closeDur)
}
}
}
After some time, I saw:
dns_open: 14ms | dns_close: 0ms
dns_open: 5019ms | dns_close: 1ms
dns_open: 25ms | dns_close: 1ms
dns_open: 27ms | dns_close: 1ms
dns_open: 20ms | dns_close: 0ms
dns_open: 5015ms | dns_close: 0ms
dns_open: 14ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 1ms
dns_open: 15ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 1ms
dns_open: 19ms | dns_close: 0ms
dns_open: 5046ms | dns_close: 0ms
To reiterate, the behavior in the actual app seemed to be every single
request. The test app went into a similar mode where a roughly every other
request failed. Here's the strace for that section:
https://gist.github.com/cholick/428df93c112067f50558
On some other runs it was quite consistently alternating slow and fast
calls (for ~300 calls in a row alternating slow/fast). Just like the Ruby,
once things get into an unhappy state they stay that way until restarting
the process. (The process ran for 12 hours and never recovered).
I can capture a Ruby strace too if you'd like, but I figured this was
more useful as it added more novel information to the mix.
These Golang jobs have run in production for months without showing
this behavior and, within a few hours of including the consul template, the
issue manifested.
|
|
|
Stack verification during application push
Hello , As of now with the "upstream buildpack" there is a restriction for stack name with which one can push a application (cflinuxfs2) Use case is to place applications on different sets of DEA's , as there is no placement pool functionality with the DEA itself. We have different sets of DEA's which are provisioned on different networks. Those DEA's have stacks property where stack name is changed from cflinuxfs2 to dev or stg (acting as a tag ) keeping the root file system same, so we can actually push a application with those stack names published by DEA. We have a proposal to actually make this stack check optional by introducing a environment variable which can be switched on from application manifest as detailed in below PR. https://github.com/cloudfoundry/compile-extensions/pull/5< https://github.com/cloudfoundry/compile-extensions/pull/5> This thing will be going inside every upstream buildpack if accepted so i thought cf-dev is the proper place to discuss this. Whole point of doing this is to avoid forking and maintaining separate offline buildpacks. -- View this message in context: http://cf-dev.70369.x6.nabble.com/Stack-verification-during-application-push-tp2783.htmlSent from the CF Dev mailing list archive at Nabble.com.
|
|
|
答复: Re: Re: Cloud Foundry deploy on suse
Tangshengjun (A) <tangshengjun@...>
We encountered this and resolved. Use this command: mount --make-rprivate / Which followed this web: http://gaijin-nippon.blogspot.in/2012/10/lxc-pivotroot-fails-on-shared-mount.htmlAnd there are many same problems which you can as a reference: https://github.com/docker/docker/issues/11382https://github.com/docker/docker/issues/1751https://github.com/lxc/lxc/issues/61http://linux.die.net/man/8/mount________________________________ 唐盛军 华为技术有限公司 Huawei Technologies Co., Ltd. Phone: 13777864354 Fax: Mobile: 13777864354 Email: tsjsdbd(a)huawei.com 地址：杭州市江虹路410号华为基地 邮编：310052 Huawei Technologies Co., Ltd. JiangHong road 410,BingJiang District,Hangzhou 310052, P.R.China http://www.huawei.com________________________________ 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! 发件人: Youzhi Zhu [mailto:zhuyouzhi03(a)gmail.com] 发送时间: 2015年11月5日 15:09 收件人: Discussions about Cloud Foundry projects and the system overall. 主题: [cf-dev] Re: Re: Cloud Foundry deploy on suse Hi Matthew I also guess it is something wrong with the file system type, then I checked the file system type when mount rootfs_lucid64 to container depot path "mnt/", it's overlayfs for suse other than aufs for ubuntu10.04, but it does support overlayfs for if you changed to overlayfs on ubuntu10.04, the app can alslo be started successfully. After that I found when stack the container file system, the command "mount" exec with "-n" option, which means do not write the mount info to /etc/mtab, but when exec on suse, it does write to the /proc/mtab. Another strange phenomenon is that the mount command is called by "unshare -m", which means do not share mount namespace with the calling process, but I can see the mounted files in the calling UTS namespace in fact, even add the "--make-rprivate" option to command mount does not work. that confused me too much. 2015-11-04 23:37 GMT+08:00 Matthew Sykes <matthew.sykes(a)gmail.com<mailto:matthew.sykes(a)gmail.com>>: wshd is simply reporting [1] the pivot_root [2] failure. It looks like you're getting an EINVAL from the call which implies warden is running in an unexpected environment. If I were to guess, I'd say that the container depot does not live on an expected file system type or location... As far as I'm aware, no work has been done to make warden run under anything but Ubuntu or CentOS recently but it's possible someone has. If nobody else has any hints, you'll likely have to look through the code and work out what's going on. [1]: https://github.com/cloudfoundry/warden/blob/76010f2ba12e41d9e8755985ec874391fb3c962a/warden/src/wsh/wshd.c#L715[2]: http://man7.org/linux/man-pages/man2/pivot_root.2.html
On Wed, Nov 4, 2015 at 7:27 AM, Youzhi Zhu <zhuyouzhi03(a)gmail.com<mailto:zhuyouzhi03(a)gmail.com>> wrote:
Hi all
We are trying to deploy cloud foundry on suse, now every CF module can start successfully, but when I push an app to CF, it occurred error, I checked the logs and found when start the container, the wshd process throw error "pivot_root: Invalid argument", anyone has seen this error before or anyone has deploy CF to other OS successfully except ubuntu?thanks.
CF version is cf-release170
suse version is suse 12 with kernel 3.12.28-4-default
--
Matthew Sykes
matthew.sykes(a)gmail.com<mailto:matthew.sykes(a)gmail.com>
|
|
|
Re: cloud_controller_ng performance degrades slowly over time
Configuring the consul agent to recurse does solve the issue. The consul agent's configuration is directory based: it loads every json file in its config directory. Since our deployment already consumes an internal release with our components in addition to cf, I've created a template as part of that which copies an additional json file (with a configuration for https://www.consul.io/docs/agent/options.html#recursors) into to the agent's configuration directory. It's a hack, but it gets us past having to build our own cf-release just to customize the consul_agent's job templates. Would you folks accept a pull request that adds "recursors" as a configuration option to https://github.com/cloudfoundry-incubator/consul-release/blob/master/jobs/consul_agent/templates/config.json.erb?Or is this work you already have in progress since you mentioned exploring having consul recurse? Or were you thinking of solving this more dynamically & consuming the existing content in resolv.conf somehow as the upstream recursors? Thanks again for all the help trying to debug this one.
On Thu, Nov 19, 2015 at 8:54 AM, Matt Cholick <cholick(a)gmail.com> wrote: Sure. Here's the Ruby:
dns_open: 8 ms | dns_close: 0 ms
dns_open: 9 ms | dns_close: 0 ms
dns_open: 10 ms | dns_close: 0 ms
dns_open: 3013 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
dns_open: 5011 ms | dns_close: 0 ms
dns_open: 5014 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
dns_open: 5012 ms | dns_close: 0 ms
dns_open: 5015 ms | dns_close: 0 ms
https://gist.github.com/cholick/f8bab2d9752728671b94
And the Go:
dns_open: 16ms | dns_close: 0ms
dns_open: 11ms | dns_close: 0ms
dns_open: 19ms | dns_close: 0ms
dns_open: 12ms | dns_close: 0ms
dns_open: 16ms | dns_close: 0ms
dns_open: 3016ms | dns_close: 0ms
dns_open: 15ms | dns_close: 0ms
dns_open: 5033ms | dns_close: 0ms
dns_open: 11ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 0ms
dns_open: 5017ms | dns_close: 0ms
dns_open: 12ms | dns_close: 0ms
dns_open: 5017ms | dns_close: 0ms
dns_open: 13ms | dns_close: 0ms
dns_open: 5015ms | dns_close: 0ms
https://gist.github.com/cholick/7d4e01dcf99588d13016
On Wed, Nov 18, 2015 at 10:10 PM, Amit Gupta <agupta(a)pivotal.io> wrote:
Thanks Matt, that's super interesting. It would be awesome to get the
strace from the Ruby thing, as well another strace from the Go thing but
this time starting from before it goes slow. I think there's some sort of
weird thing that happens once, and then after that happens, the fact that
Consul (or any other always-SERVFAIL server, e.g. Dmitriy's little Ruby DNS
server) is present makes all subsequent requests slow. So I'd like to see
strace from both the Ruby and the Go, with enough before and after the
slowness starts to establish the same pattern of behaviour.
The alternating slow/fast stuff with Go is interesting. Not clue yet
what that could be, maybe multiple goroutines?
On Wed, Nov 18, 2015 at 4:13 PM, Matt Cholick <cholick(a)gmail.com> wrote:
So things got a little more interesting yesterday. We have some custom
Golang jobs for auditing and some other purposes. A recent change added the
consult_agent template to the box with these jobs and I saw similar
behavior: requests with dns resolution taking +5s consistently, fixable by
restarting the process. I wrote a small Golang app to try and reproduce it.
I got similar, but not identical behavior in the test app.
package main
import (
"net"
"fmt"
"time"
)
func main() {
for {
startOpen := time.Now()
conn, err := net.Dial("tcp", "api.useast.appfog.qa.ctl.io:http")
if err != nil {
fmt.Printf("%#v", err)
} else {
endOpen := time.Now()
conn.Close()
endClose := time.Now()
openDur := endOpen.Sub(startOpen) / 1e6
closeDur := endClose.Sub(endOpen) / 1e6
fmt.Printf("dns_open: %dms | dns_close: %dms\n", openDur, closeDur)
}
}
}
After some time, I saw:
dns_open: 14ms | dns_close: 0ms
dns_open: 5019ms | dns_close: 1ms
dns_open: 25ms | dns_close: 1ms
dns_open: 27ms | dns_close: 1ms
dns_open: 20ms | dns_close: 0ms
dns_open: 5015ms | dns_close: 0ms
dns_open: 14ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 1ms
dns_open: 15ms | dns_close: 0ms
dns_open: 5018ms | dns_close: 1ms
dns_open: 19ms | dns_close: 0ms
dns_open: 5046ms | dns_close: 0ms
To reiterate, the behavior in the actual app seemed to be every single
request. The test app went into a similar mode where a roughly every other
request failed. Here's the strace for that section:
https://gist.github.com/cholick/428df93c112067f50558
On some other runs it was quite consistently alternating slow and fast
calls (for ~300 calls in a row alternating slow/fast). Just like the Ruby,
once things get into an unhappy state they stay that way until restarting
the process. (The process ran for 12 hours and never recovered).
I can capture a Ruby strace too if you'd like, but I figured this was
more useful as it added more novel information to the mix.
These Golang jobs have run in production for months without showing this
behavior and, within a few hours of including the consul template, the
issue manifested.
|
|
|
Re: CF-RELEASE v202 UPLOAD ERROR
Parthiban Annadurai <senjiparthi@...>
|
|
|
Re: [abacus] Handling Notifications
Yes, that's why I was suggesting one doc per registration keyed by trigger criteria. After some further thought, my original suggestion doesn't seem to make much sense since it would mean every single document would have to be fetched for every event to see if that particular URL matches the event. I thought a bit more about this. We could set a timeout (using our circuit breaker module for example) causing slow Webhooks to error and then get handled like other errors. I think this is a good approach. Right, so I'd vote for a separate service initially for a cleaner separation of concerns, and we can always merge it back in later if we want. Agreed. I was thinking about a kind of 'cursor' mechanism or something along the lines of what CF app events provide, where you can request notifications from a sequence number, a timestamp, or a page number for example... That cursor mechanism will be handy too when you'll want to replay missed notifications after a failure. Makes sense? Yeah, that makes sense now. That kind of functionality will probably be necessary since the service would probably will run into errors on occasion when processing, and it'll need a way to keep track of where it last left off. Also, we ended up discussing a little bit on the high level on how to do the matching algorithm, so I'll relay it here. With the many algorithms already out there, we'll be using one similar to the tree-based approaches for matching. Here's a high-level overview: Each tree will (at the moment) be scoped to an organization. Each node of the tree is a predicate (ie: quantity > 10) to compare the event against. An event in this case will be the usage report. The event starts at the root of the tree. Each branch is a predicate. The event traverses down the branch where the predicate evaluates true. Eventually, the algorithm can reach a leaf node. This leaf node will be a table sorted by its keys. Each entry in this table will be a subscribtion URL. The table being sorted would allow the algorithm to grab the range of URLs to notify rather than having to check each and every subscriber in the node. ie: A wants to be notified on quantity > 5. B wants to be notified on quantity > 10. An event with quantity = 14 comes in. The algorithm should be able to just check B and grab both A & B to be notified. Thoughts? Comments?
|
|
|
Re: Made a PHP 7 enabled buildpack
Christian Stocker <me@...>
Hi JT That's right, as all extensions have to be adapted to PHP 7, many non-core extensions are not ready yet, but I didn't check thoroughly currently. We have a fairly big symfony based application, which runs fine on our build pack, but we depend on not so many extensions, just imagick from non-core and that's available for PHP 7 already Here's the Dockerfile I needed to create the binaries https://gist.github.com/chregu/0be89b4e88f2c3db202cLooking forward to official PHP 7 support, but I can imagine that will be a lot of work with all those extensions you support christian We have a fairly big symfony based application
On 19.11.15 22:22, JT Archie wrote: Hi, Christian. I'm from the buildpacks team.
Last time we investigated PHP7, we ran into the same issue, no
extensions besides core work with PHP7. When we investigated, it
appeared to be a chicken and egg problem. Most of the extensions said
they wouldn't update till PHP7 officially dropped.
Can people deploy their apps with just core PHP7?
We are also awaiting final release before we add it to the buildpack.
This is RC7, so hopefully we are close.
Please keep us up to date though on anything you find.
Kind Regards,
JT
On Thu, Nov 19, 2015 at 2:57 PM, Christian Stocker <me(a)chregu.tv
<mailto:me(a)chregu.tv>> wrote:
Hi all
Today I added PHP 7.0.0RC7 to my php buildpack fork. In case you're
interested in testing PHP 7.0 on CloudFoundry today, just add
"https://github.com/chregu/cf-php-varnish-buildpack#php-7" as a
buildpack.
It doesn't have many extensions outside the standard ones (acutally
just one, imagick), is not very well tested and also includes my
varnish extension (but that's not enabled, if you don't change any
setting). Apart from that it's like the standard php-buildpack and
should be quite up-to-date with merges from that.
Feel free to do whatever you want with it (and I'm sure, the
official maintainers will soon add official PHP 7.0 support)
Greetings
Christian
--
Liip AG // Limmatstrasse 183 // CH-8005 Zurich
Tel +41 43 500 39 81 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x1575A89B
|
|
|
Re: Made a PHP 7 enabled buildpack
Hi, Christian. I'm from the buildpacks team.
Last time we investigated PHP7, we ran into the same issue, no extensions
besides core work with PHP7. When we investigated, it appeared to be a
chicken and egg problem. Most of the extensions said they wouldn't update
till PHP7 officially dropped.
Can people deploy their apps with just core PHP7?
We are also awaiting final release before we add it to the buildpack. This
is RC7, so hopefully we are close.
Please keep us up to date though on anything you find.
Kind Regards,
JT
toggle quoted message
Show quoted text
On Thu, Nov 19, 2015 at 2:57 PM, Christian Stocker <me(a)chregu.tv> wrote: Hi all
Today I added PHP 7.0.0RC7 to my php buildpack fork. In case you're
interested in testing PHP 7.0 on CloudFoundry today, just add "
https://github.com/chregu/cf-php-varnish-buildpack#php-7" as a buildpack.
It doesn't have many extensions outside the standard ones (acutally just
one, imagick), is not very well tested and also includes my varnish
extension (but that's not enabled, if you don't change any setting). Apart
from that it's like the standard php-buildpack and should be quite
up-to-date with merges from that.
Feel free to do whatever you want with it (and I'm sure, the official
maintainers will soon add official PHP 7.0 support)
Greetings
Christian
|
|
|
Made a PHP 7 enabled buildpack
Christian Stocker <me@...>
Hi all Today I added PHP 7.0.0RC7 to my php buildpack fork. In case you're interested in testing PHP 7.0 on CloudFoundry today, just add " https://github.com/chregu/cf-php-varnish-buildpack#php-7" as a buildpack. It doesn't have many extensions outside the standard ones (acutally just one, imagick), is not very well tested and also includes my varnish extension (but that's not enabled, if you don't change any setting). Apart from that it's like the standard php-buildpack and should be quite up-to-date with merges from that. Feel free to do whatever you want with it (and I'm sure, the official maintainers will soon add official PHP 7.0 support) Greetings Christian
|
|
|
