|
Message Broker Version Verification
Masumi Ito
I have a question of how to handle API Version Header of service broker
(X-Broker-Api-Version) in http request header. First of all, I found the CF manual mentioned as follows; === This header will be useful in future minor revisions of the API to allow brokers to reject requests from Cloud Controllers that they do not understand. === In addition, spring-boot-cf-service-broker, which is one of reference implementations for service brokers, seems to verify if the X-Broker-Api-Version value is exactly equal to the expected API for each request it receives by default. Does the CF community recommend that service broker should reject any requests from CC if X-Broker-Api-Version value is not equal to the API version which it expects? - X-Broker-Api-Version = 2.5 - API version for a service broker to understand =2.4 If so, personally this policy does not make sence to me because it will cause frequent modifications of service brokers whenever CF version is updated. I prefer the service broker accepts requests from CC which exposes the newer X-Broker-Api-Versions it understand so that it can work with the latest CF without code modifications. -- View this message in context: http://cf-dev.70369.x6.nabble.com/Message-Broker-Version-Verification-tp428.html Sent from the CF Dev mailing list archive at Nabble.com. |
|
|
|
Re: cloud foundry - 413 Request Entity Too Large
James Bayer
are you sure that the request isn't making it all the way to the app
toggle quoted message
Show quoted text
container? are there features of netty that you can log the request as it's coming in with lots of logging for different aspects of the request lifecycle? e.g. tcp connection established, etc. On Mon, Jun 15, 2015 at 7:47 AM, avia <Avia.Ohana(a)emc.com> wrote:
Hi James, --
Thank you, James Bayer |
|
|
|
Buildpacks PMC - 2015-06-15 notes
Mike Dalessio
Hello everybody,
We had a meeting of the Buildpacks PMC today, permanent notes are at: https://github.com/cloudfoundry/pmc-notes/blob/master/Buildpacks/2015-06-16-buildpacks.md which I've helpfully snapshotted in this email below. Cheers, -mike --- *# Buildpacks PMC Meeting 2015-06-15* *## Agenda* 1. Update on Java Buildpack (Ryan Morgan) 2. Update on core Buildpacks (Mike Dalessio) 3. Open Discussion *## Attendees* * Chip Childers, Cloud Foundry Foundation * Alex Tarpinian, IBM * Michael Fraenkel, IBM * Ruben Koster, Stark and Wayne * Ryan Morgan, Pivotal * Mike Dalessio, Pivotal *## Update on Java Buildpack (Ryan Morgan)* * Investigation on an OOM issue raised on cf-dev: https://www.pivotaltracker.com/story/show/94381284 * Spike on Lunk SDK integration (Hardware security device from SafeNet): https://www.pivotaltracker.com/story/show/96530962 * Next release will be 3.1, likely by the end of June. *## Update on core Buildpacks (Mike Dalessio)* *__Tracks__* * Started taking over maintenance of [rootfs][stacks] * Working on building CF-specific binaries. * Moved to Concourse. Will be made public shortly. * [upcoming] Will soon be removing support for lucid64 rootfs. Some discussion with Michael Fraenkel about the timing of removal of lucid64 from `cf-release`, and whether this impacts the buildpacks work. We'll loop up with Dieu in the Runtime PMC tomorrow. *__Releases__* * Released [staticfile-buildpack][static] which eliminates the static linking of libpcre3 in the expectation of an upstream patch for CVE-2015-3210 to rootfs. * Released [python-buildpack][python] which updates to [python 2.7.10][pyrelease] * Released [php-buildpack][php] which includes some security improvements and updates to PHP interpreters. * Released [nodejs-buildpack][nodejs] which updates to nodejs 0.12.4. [stacks]: https://github.com/cloudfoundry/stacks [static]: https://github.com/cloudfoundry/staticfile-buildpack/releases [python]: https://github.com/cloudfoundry/python-buildpack/releases [pyrelease]: https://hg.python.org/cpython/raw-file/15c95b7d81dc/Misc/NEWS [php]: https://github.com/cloudfoundry/php-buildpack/releases [nodejs]: https://github.com/cloudfoundry/nodejs-buildpack/releases Michael Fraenkel noted that he submitted a small PR to `binary-buidpack`, which Mike Dalessio will review ASAP. *## Open Discussion* No additional topics were covered. |
|
|
|
Re: cloud foundry - 413 Request Entity Too Large
avia <Avia.Ohana@...>
Hi James,
The 413 error doesn't come from our app. Our app doesn't get the POST request with body size >= ~12MB. We are using netty jax-rs. All I can see in app logs is: 2015-06-15T14:28:55.000+00:00 [RTR] OUT listenerendpoint.appscf.wysdm.lab.emc.com:80 - [15/06/2015:14:28:55 +0000] "POST /listener-endpoint-api/agent/nbustomaster/report HTTP/1.1" 413 0 "-" "Apache-HttpClient/4.2.1 (java 1.5)" 10.98.61.131:53703 x_forwarded_for:"10.98.63.219, 10.98.61.131" vcap_request_id:4508262e-26e9-4837-4f08-505b65863fec response_time:0.304191621 app_id:582630d6-de94-41b9-a539-0e3a4fad1725 any idea? -- View this message in context: http://cf-dev.70369.x6.nabble.com/cf-dev-cloud-foundry-413-Request-Entity-Too-Large-tp350p425.html Sent from the CF Dev mailing list archive at Nabble.com. |
|
|
|
Multi-node CCNG Problem
tan_bw@...
Hi there:
I deployed 2 CCNG nodes in my servers.Since they've connected to the same database,they always pull a same asynchronous task from my DB.I found it's hardly to do the synchronous job by the DB.Is there any good idea? tan_bw(a)163.com |
|
|
|
Multi-node CCNG Problem
tan_bw@...
Hi there:
I deployed 2 CCNG nodes in my servers.Since they've connected to the same database,they always pull a same asynchronous task from my DB.I found it's hardly to do the synchronous job by the DB.Is there any good idea? tan_bw(a)163.com |
|
|
|
I: R: Re: Log connections from security groups - bosh lite
Michael Grifalconi <michael.grifalconi@...>
Hello all,
toggle quoted message
Show quoted text
as I had no response, and I wasn't able to progress, I'm bumping this email from last week Thank you! Best regards, Michael -------- Messaggio originale -------- Da: "Michael Grifalconi" <michael.grifalconi(a)studenti.unimi.it> Data: 08/giu/15 9:31:55 m. Oggetto: R: Re: [cf-dev] Log connections from security groups - bosh lite A: Discussions about Cloud Foundry projects and the system overall. <cf-dev(a)lists.cloudfoundry.org> Hello, I post some more info: Kernel logging is enabled because inside the DEA, i can see: cat /etc/rsyslog.conf [...] $IncludeConfig /etc/rsyslog.d/*.conf cat /etc/rsyslog.d/enable-kernel-logging.conf $ModLoad imklog after pushing an app, I see on the DEA the correct rules: -A warden-i-18nvgifiemi -p tcp -m tcp --dport 80 -g warden-i-18nvgifiemi-log -A warden-i-18nvgifiemi-log -p tcp -m conntrack --ctstate INVALID,NEW,UNTRACKED -j LOG --log-prefix "warden-i-18nvgifiemi " but on /var/log/messages I only get: Jun 8 07:03:26 localhost kernel: [ 3256.433021] IPv6: ADDRCONF(NETDEV_CHANGE): w-18nvgifiemg-0: link becomes ready the php application pushed: xx(a)boshClient:~/myPhpApp$ cat index.php <html> <head> <title>PHP Test</title> </head> <body> <?php echo '<p>Hello PHP from the server at:</p>'; echo $_SERVER['SERVER_ADDR']; echo '<p>hi from hostname:</p>'; $curl = curl_init(); curl_setopt($curl, CURLOPT_URL, 'http://xxxxxxx'); $result = curl_exec($curl); echo gethostname(); ?> </body> </html> When I browse this application page, I see the page from the webserver on xxxx called from curl, but I don't get ant log. bosh stemcells +---------------------------------------------+---------+--------------------------------------+ | Name | Version | CID | +---------------------------------------------+---------+--------------------------------------+ | bosh-warden-boshlite-ubuntu-trusty-go_agent | 2776* | c5ac6590-13ec-4ba2-6fa9-e78cf553c4e6 | +---------------------------------------------+---------+--------------------------------------+ -------------------------------------------------------------------- xx(a)boshClient:~$ cf security-groups Getting security groups as admin OK Name Organization Space #0 public_networks #1 dns #2 logging myOrg myDevSpace xx(a)boshClient:~$ cf security-group logging Getting info for security group logging as admin OK Name logging Rules [ { "destination": "0.0.0.0/0", "log": true, "ports": "80", "protocol": "tcp" } ] Organization Space #0 myOrg myDevSpace tried with protocol: all and :tcp and the port where my local apache server on LAN is listening. Any suggestion is appreciated! Regards, Michael Il 06/06/15 09:25, Dieu Cao <dcao(a)pivotal.io> ha scritto:
|
|
|
|
R: Re: R: Re: Monitor all outbound connections from apps in warden
Michael Grifalconi <michael.grifalconi@...>
Hello Joseph,
toggle quoted message
Show quoted text
I was able to do it, but it was not accurate enough, as 'netstat' prints the open connections in a specific moment, is good for persistent connection but can not catch a fast PUSH request for example.. I was following the suggestion of Dieu Cao but I'm experiencing some problems, I'm going to bump that email right now! Regards, Michael Il 12/06/15 11:36, CF Runtime <cfruntime(a)gmail.com> ha scritto:
|
|
|
|
Re: Is there any officail Chinese docs?
Wayne E. Seguin
I am interested in seeing an effort to add zh_cn docs.
toggle quoted message
Show quoted text
On Tue, Jun 9, 2015 at 5:31 PM, Kim Hoffman <khoffman(a)pivotal.io> wrote:
The CF documentation team isn't aware of any Chinese docs. There's nothing |
|
|
|
Re: Post: Cloud Foundry Advisory Board Meeting Notes - 2015 June
Phil Whelan
Hi Paul,
Thanks for the great feedback! You make a good point. Although, I think Pivotal have earned their fair share of mentions. Also companies, which are named, are investing a great deal in development of Cloud Foundry and also deserve recognition by name, in my opinion. Where this breaks down is in situations where the person speaking on the CAB call is not from the same company as those working on the component. For instance, I believe all the developers of the CLI are all from IBM, but the update will come from the PM who works for Pivotal. This cross-pollination of developers fom different companies is a great thing and what seems to be aim of the Dojos. So, yes, the "..from Pivotal" may not be fully representative of all the contributions of all parties and it would be good to find a way to expose this information in communications such as these CAB notes. I'll have a think about this for the next one. Cheers, Phil On Sat, Jun 13, 2015 at 3:03 AM, Paul Sherwood < paul.sherwood(a)codethink.co.uk> wrote: On 2015-06-12 21:19, Phil Whelan wrote:Ive just posted a write-up of the Cloud Foundry Advisory Board MeetingThanks for this - it's a great write-up. One thing I noticed as a newbie |
|
|
|
Re: How random is Metron's Doppler selection?
Stuart Charlton
Mike,
Actually, this might explain why some of our customers are so frustratedI'm not sure this is a specific issue with Doppler, as I've dealt with syslog aggregated servers in the past with Splunk and generally I've been able to merge stack traces (with some false mergers on corner cases) with some props.conf voodoo setting up custom linebreaker clauses for Java stack traces. Usually Log4J or whatnot can be configured to emit a predictable field like an extra timestamp ahead of any any app log messages so I can differentiate a multi-line event from single. Multiple syslog drains shouldn't be a problem because Splunk will merge events based on the date you tell it to merge on. -- Stuart Charlton Pivotal Software | Field Engineering Mobile: 403-671-9778 | Email: scharlton(a)pivotal.io |
|
|
|
Re: Post: Cloud Foundry Advisory Board Meeting Notes - 2015 June
Paul Sherwood <paul.sherwood@...>
On 2015-06-12 21:19, Phil Whelan wrote:
Ive just posted a write-up of the Cloud Foundry Advisory BoardThanks for this - it's a great write-up. One thing I noticed as a newbie here - lots of '.. from Pivotal'. I very much appreciate that Pivotal is leading and contributing to the project in many ways, but I believe CF aims to become more inclusive and involve more non-Pivotal folks. So it might be worth considering for future just to name the contributors without mentioning their employer, to avoid creating the false impression that only Pivotal folks are contributing. br Paul |
|
|
|
Re: Post: Cloud Foundry Advisory Board Meeting Notes - 2015 June
Ferran Rodenas <frodenas@...>
Thanks Phil!
toggle quoted message
Show quoted text
- Ferdy 2015-06-12 22:19 GMT+02:00 Phil Whelan <philw(a)activestate.com>: Hi, |
|
|
|
Re: How random is Metron's Doppler selection?
John Tuley <jtuley@...>
I can't speculate as to the future of CF and whether or not a particular
toggle quoted message
Show quoted text
feature will someday be included. But I can suggest a workaround: aside from very paranoid application security group settings, there should be nothing preventing your application from sending syslog to your external drain already, since apps can make outbound connections. Obviously, this wouldn't also go through Loggregator, and so wouldn't be available on `cf logs`. But perhaps your logging utility can be configured to send to both syslog and stdout/stderr simultaneously? – John Tuley On Fri, Jun 12, 2015 at 2:40 PM, Mike Heath <elcapo(a)gmail.com> wrote:
That's fair. |
|
|
|
Re: Log drain for an app
Daniel Mikusa
Thanks John! I'll play with that and see if I can make it work.
toggle quoted message
Show quoted text
Dan On Fri, Jun 12, 2015 at 4:26 PM, John Tuley <jtuley(a)pivotal.io> wrote:
Dan, |
|
|
|
Re: Post: Cloud Foundry Advisory Board Meeting Notes - 2015 June
Wayne E. Seguin
Thanks Phil!!!
toggle quoted message
Show quoted text
On Fri, Jun 12, 2015 at 4:19 PM, Phil Whelan <philw(a)activestate.com> wrote:
Hi, |
|
|
|
Re: Post: Cloud Foundry Advisory Board Meeting Notes - 2015 June
Dieu Cao <dcao@...>
Thanks Phil! As always, a great write up.
toggle quoted message
Show quoted text
On Fri, Jun 12, 2015 at 1:19 PM, Phil Whelan <philw(a)activestate.com> wrote:
Hi, |
|
|
|
Re: Syslog Drain to Logstash Problems
Josh Ghiloni
That did solve our problems. Thanks everyone!
toggle quoted message
Show quoted text
Josh Ghiloni Senior Consultant 303.932.2202 o | 303.590.5427 m | 303.565.2794 f jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com> ECS Team Technology Solutions Delivered ECSTeam.com<http://ECSTeam.com> On Jun 12, 2015, at 09:20, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote:
It appears that we do not have the syslog_drain_binder templates as Mike mentioned — thanks guys! We’ll update that and give ‘er a go. Josh Ghiloni Senior Consultant 303.932.2202 o | 303.590.5427 m | 303.565.2794 f jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com> ECS Team Technology Solutions Delivered ECSTeam.com<http://ecsteam.com/> On Jun 11, 2015, at 11:10, John Tuley <jtuley(a)pivotal.io<mailto:jtuley(a)pivotal.io>> wrote: Mike, Thanks for finding that. I've filed a bug<https://www.pivotaltracker.com/story/show/96801752> to get the README fixed. – John Tuley On Thu, Jun 11, 2015 at 10:22 AM, Mike Jacobi <jacobi(a)adobe.com<mailto:jacobi(a)adobe.com>> wrote: We had the same problem due to missing templates in our manifest. We initially used the example manifest snippet shown at https://github.com/cloudfoundry/loggregator which mentions only the doppler template. Looking at https://github.com/cloudfoundry/loggregator/blob/develop/manifest-templates/cf-lamb.yml we later determined that we also needed the syslog_drain_binder and metron_agent templates for a complete loggregator deployment. -Mike On Jun 10, 2015, at 9:35 AM, Steve Wall <steve.wall(a)primetimesoftware.com<mailto:steve.wall(a)primetimesoftware.com>> wrote: I was able submit a log entry from the loggregator VM using - nc -w0 10.xx.xx.xx 5000 <<< "logging from loggregator" and to test UDP nc -u -w0 10.xx.xx.xx 5000 <<< "logging from loggregator" Which leads me to believe the networking is working properly. Any other thoughts? Thanks! Steve On Wed, Jun 3, 2015 at 6:14 PM, Josh Ghiloni <jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>> wrote: We’ll check that, thanks! Josh Ghiloni Senior Consultant 303.932.2202<tel:303.932.2202> o | 303.590.5427<tel:303.590.5427> m | 303.565.2794<tel:303.565.2794> f jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com> ECS Team Technology Solutions Delivered ECSTeam.com<http://ecsteam.com/> On Jun 3, 2015, at 15:41, John Tuley <jtuley(a)pivotal.io<mailto:jtuley(a)pivotal.io>> wrote: Steve, Until recently (cf-release v198), binding a syslog service required restarting the app. If you're post-v198, it should Just Work. However, one of the things that could be in your way is network security. In order to forward logs to your drain, your loggregator servers must be able to access that server. This is the most common cause we see of systems failing to forward to syslog drains. Please let us know if you have more questions. – John Tuley On Wed, Jun 3, 2015 at 12:37 PM, Steve Wall <steve.wall(a)primetimesoftware.com<mailto:steve.wall(a)primetimesoftware.com>> wrote: Hello, We are having problems draining log messages to Logstash. The drain is setup as a user provided service. cf cups logstash-drain -l syslog://xx.xx.xx.xx:5000 And then bound to the service. cf bind-service myapp logstash-drain But no log messages are coming through to Logstash. Or more specifically, we are using ELK and the messages aren't seen through Kibana. We were able to log into the DEA and using netcat (nc), messages were successfully submitted to the ELK stack. nc -w0 -u xx.xx.xx.xx 5000 <<< "logging from remote" Any suggestions on how to debug this further? -Steve _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev _______________________________________________ cf-dev mailing list cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org> https://lists.cloudfoundry.org/mailman/listinfo/cf-dev |
|
|
|
Re: How random is Metron's Doppler selection?
Mike Heath
That's fair.
toggle quoted message
Show quoted text
I think Mike Youngstrom is right. All of our logging problems would go away if our applications could talk syslog to Loggregator. Capturing stdout and stderr is certainly convenient, but it's not great for dealing with stack traces. -Mike On Fri, Jun 12, 2015 at 8:38 AM, John Tuley <jtuley(a)pivotal.io> wrote:
Mike, |
|
|
|
Re: Log drain for an app
John Tuley <jtuley@...>
Dan,
toggle quoted message
Show quoted text
I see three questions in your email, which I'll try to address in turn: - *"Can my application send logs with a unique token?"* – Your application can add any text it likes to the message, of course. When they're sent to the syslog drain, the messages will be embedded in a syslog-formatted line. Looking at Logsene's syslog example <https://sematext.atlassian.net/wiki/display/PUBLOGSENE/Syslog#Syslog-Example>, it seems that they expect the syslog message to contain a JSON payload with the token as a property. If your application produces that JSON, I think it would be compatible. However, the Loggregator system does not wrap bare loglines into that format, nor can it be configured to do so without rewriting code. - *"Do multiple apps on CF send logs from the same IP address?"* – Yes. But it's worse than that: not only do multiple app streams come from the same IP address, but a single application's stream can come from multiple IP addresses. So this is probably not good from Logsene's point of view. - *"Is Loggregator's HTTPS transport compatible with the ElasticSearch API?"* – No. Loggregator makes a POST request to the HTTPS endpoint by putting a syslog-formatted line into the body of the request. It does not have support for building an ElasticSearch-compatible JSON payload around the message. It appears to me that the best shot you have of compatibility with Logsene is having your application build messages in the expected way, with JSON wrapper (if that's truly needed; my quick read of the syslog example I linked above was unclear). Keep in mind that Loggregator sends each *line* separately, so your JSON payload must be a single line to be transmitted correctly. – John Tuley On Fri, Jun 12, 2015 at 11:13 AM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:
Hello, |
|
|