Great stuff Dr Nic, lovely blog post!

On Thu, Apr 13, 2017 at 7:26 AM, Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

*Release notes*: https://github.com/cloudfoundry-community/docker-
boshrelease/releases/tag/v30.0.0

The docker-boshrelease was first introduced Apr 14, 2014 - three years ago
- by the legendary Ferdy. It has been used in production systems for years
- both running static clusters of containers, and as an API allowing
dynamic provisioning/deprovisioning of containers (historically this was
via Cloud Foundry) via the https://github.com/cloudfoundry-community/cf-
containers-broker companion project.

*To celebrate the dual birthdays* - this repository turning three and
BOSH itself turning five https://www.cloudfoundry.org/bosh-turns-five/ -
we've done a major upgrade to this project to bring it into line with the
exciting features in BOSH 2.0.

This release also includes the introduction of a companion project
https://github.com/cloudfoundry-community/docker-broker-deployment - the
one-stop shop for deploying the Open Service Broker API that can deploy
anything as a service, via Docker!

I've also published a "getting started" guide at
https://www.starkandwayne.com/blog/adding-docker-based-
services-to-your-cloud-foundry-with-bosh2/ which includes links to
getting started with bosh 2.0, and deploying CF using the fabulous new
bosh2 cli and *-deployment repos.

Happy birthday BOSH!
Dr Nic

--
Dr Nic Williams
Stark & Wayne LLC
http://starkandwayne.com
+61 437 276 076 <+61%20437%20276%20076>
twitter @drnic

*Release notes*:
https://github.com/cloudfoundry-community/docker-boshrelease/releases/tag/v30.0.0

The docker-boshrelease was first introduced Apr 14, 2014 - three years ago
- by the legendary Ferdy. It has been used in production systems for years
- both running static clusters of containers, and as an API allowing
dynamic provisioning/deprovisioning of containers (historically this was
via Cloud Foundry) via the
https://github.com/cloudfoundry-community/cf-containers-broker companion
project.

*To celebrate the dual birthdays* - this repository turning three and BOSH
itself turning five https://www.cloudfoundry.org/bosh-turns-five/ - we've
done a major upgrade to this project to bring it into line with the
exciting features in BOSH 2.0.

This release also includes the introduction of a companion project
https://github.com/cloudfoundry-community/docker-broker-deployment - the
one-stop shop for deploying the Open Service Broker API that can deploy
anything as a service, via Docker!

I've also published a "getting started" guide at
https://www.starkandwayne.com/blog/adding-docker-based-services-to-your-cloud-foundry-with-bosh2/
which includes links to getting started with bosh 2.0, and deploying CF
using the fabulous new bosh2 cli and *-deployment repos.

Happy birthday BOSH!
Dr Nic

--
Dr Nic Williams
Stark & Wayne LLC
http://starkandwayne.com
+61 437 276 076
twitter @drnic

PR away!

Generally, what would happen is the the bots would remind you to file a CLA
before they are updated with your GH ID. But closing then reopening the PR
would kick the bot to mark it as OK to merge after we get the CLA filed and
bots configured. ;-)

On Thu, Apr 13, 2017 at 6:48 AM Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote:

Hi guys,

Today I have submitted the CLA to the corresponding email address, did I
need to wait for any confirmation from the foundation to submit a pull
request or that's all that is required.

Thanks,
Leandro.-

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Hi guys,

Today I have submitted the CLA to the corresponding email address, did I
need to wait for any confirmation from the foundation to submit a pull
request or that's all that is required.

Thanks,
Leandro.-

Could we use time at the CF summit for f2f discussions?

There are also some comments in the docs. I added one more today w.r.t. to
the BOSH CPI and interface in Unik.

Anyhow, we could of course have more than one discussion.

Best,

Max

--
max
http://maximilien.org
http://blog.maximilien.com

Hi Daniel,

Sorry for the late reply and thank you for the comments. Please see my answers inline.

Cloud Foundry aside, how does Unik go from receiving some app code to know exactly which kernel features are needed for the application at run time? This is the part that seems most magical to me.

First, Unik is not the one who make that decision, this decision is being done by the tool that build the unikernel and it is different tool for each unikernel type.

For example in IncludeOS, the mechanism used for extracting only what is needed from the operating system, is the one provided by default by modern linkers. Each part of the OS is compiled into an object-file, such as ip4.o, udp.o, pci_device.o etc., which are then combined using ar to form a static library os.a. When a program links with this library, only what’s necessary will automatically be extracted by the linker and end up in the final binary. To facilitate this build process a custom toolchain has been created.

Hope that make sense.

Where is the Unik daemon running - presumably somewhere of the operators choice, mostly likely as a BOSH-deployed job?

Yes, it is the Operators jobs and it will be smart to create BOSH release to UniK - right now the install process is done by running 'make'.

What happens if the Unik daemon dies - is it stateful? Will unikernels continue to run and be manageable?

The unikernels will continue running but will not be managed by UniK until the daemon will be restarted - just like docker.

Does the unikernel image get created at app staging time?

If the image is not pre built it will be built it, otherwise the existence image will be used.

Has there been any discussion about how to strategically implement this alongside Diego, instead of the tactical solution of 'going through' Diego?

I am going to set time with Chip help and we can all discuss it together. I think that clean integration should be done in Garden. But it should be discussed and decided by the community.

I hope that clarify some of your concerns and please feel free to ask me any question.

Thanks,
Idit

On Mar 23, 2017, at 4:32 PM, Daniel Jones <daniel.jones(a)engineerbetter.com> wrote:

Hi Idit,

Thanks for sending out the proposal, and thanks for giving your talk in Santa Clara last year, which I attended and was excited by.

I've read the proposal and heard the talk, but I'll be frank - I still don't get it. That may well be because I'm a simpleton who doesn't know much about kernels, let alone unikernels, but if I don't ask some silly questions I'll probably never know.

Cloud Foundry aside, how does Unik go from receiving some app code to know exactly which kernel features are needed for the application at run time? This is the part that seems most magical to me.
Where is the Unik daemon running - presumably somewhere of the operators choice, mostly likely as a BOSH-deployed job?
What happens if the Unik daemon dies - is it stateful? Will unikernels continue to run and be manageable?
Does the unikernel image get created at app staging time?
Has there been any discussion about how to strategically implement this alongside Diego, instead of the tactical solution of 'going through' Diego?

I'm excited by the promise of unikernels - being able to cut out so much bloat and indirection would be a massive win for efficiency if they usurped containers as a unit of currency. I wonder how much CO2 emission we could avoid by stripping abstraction away, instead of piling it on!

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
EngineerBetter Ltd <http://www.engineerbetter.com/> - UK Cloud Foundry Specialists

On 16 March 2017 at 21:09, Michael Maximilien <mmaximilien(a)gmail.com <mailto:mmaximilien(a)gmail.com>> wrote:
Thanks for this submission Idit and Dell/EMC.

I look forward to comments from community as we work this though the CF-extensions process.

Best.

On Thu, Mar 16, 2017 at 1:25 PM Idit Levine <idit.levine(a)gmail.com <mailto:idit.levine(a)gmail.com>> wrote:
One clarification, we propose it to the CF incubation program.

On Mar 16, 2017, at 3:59 PM, Idit Levine <idit.levine(a)gmail.com <mailto:idit.levine(a)gmail.com>> wrote:

Hi all,

We at Dell EMC would like to propose to contribute project unik (https://github.com/emc-advanced-dev/unik <https://github.com/emc-advanced-dev/unik>) and its integration with Cloud Foundry (https://github.com/emc-advanced-dev/cf-unik-buildpack <https://github.com/emc-advanced-dev/cf-unik-buildpack>) to Cloud Foundry community.

You can find the full official proposal at: https://docs.google.com/document/d/1Q9GakKpm6DMniJpWB-fqhE13SSPaj4-3sOWZ-I5nVyA/edit?usp=sharing <https://docs.google.com/document/d/1Q9GakKpm6DMniJpWB-fqhE13SSPaj4-3sOWZ-I5nVyA/edit?usp=sharing>
We of course welcome input and feedback on the proposal via inline commentary on the proposal document or directly to me.

Thanks,
Idit

--
dr.max Sent from my iPhone http://maximilien.org <http://maximilien.org/>

Hi,


On Linux or MacOS the following shell scripts may help. They show details across organizations and spaces you have access to.
https://github.com/rakutentech/cf-tools/blob/master/cf-applist.sh
https://github.com/rakutentech/cf-tools/blob/master/cf-routelist.sh

Best regards,
Stanislav German-Evtushenko

Hi,

To find *Org name* you could use something like

*cf curl /v2/apps/`cf app spring-music --guid`/summary | jq -r
".space_guid" | xargs -I '<guid>' cf curl '/v2/spaces/<guid>' | jq -r
".entity.organization_url" | xargs -I '<org_url>' cf curl '<org_url>' | jq
-r '.entity.name <http://entity.name>' | xargs -I '<org_name>' echo Org
Name : '<org_name>' *

To find *Space name* you could use something like

*cf curl /v2/apps/`cf app spring-music --guid`/summary | jq -r
".space_guid" | xargs -I '<guid>' cf curl '/v2/spaces/<guid>' | jq -r
".entity.name <http://entity.name>" | xargs -I '<space_name>' echo Space
name : '<space_name>' *

Replace *spring-music *with your app name

Note. You might have to install jq [0] or else replace with something like
sed, awk and grep


[0] - https://stedolan.github.io/jq/

--
Kind Regards,

David Farrell

Pivotal Global Support Services (GSS)

Email: dafarrell(a)pivotal.io
Office #: +353 21 4238482
Office Hours: Mon-Fri 8:30 AM to 5PM <GMT+1>
Out of Office Hours Contact +1 877-477-2269

Pivotal GSS Contact & Escalations:
https://discuss.zendesk.com/hc/en-us/articles/203809556



pivotal.io

Hi, all,

Nǐ hǎo (你好) from Beijing.

Quick reminder of the CloudFoundry Community Advisory Board (CAB) call next Wednesday, April 19th @ 8a PDT (UTC -7). All info in link [1].

Remember, no more status updates but rather project highlights, open discussions, and community presentations. And we have some good ones lined up for you:

1. David Sabeti (Pivotal) on new cf-deployment project [2].

2. Dmitriy Kalinin (Pivotal) on Turbulence BOSH release [3].

3. Dr. Nic Williams (Stark & Wayne) on using BOSH links, cloud-config, and other v2 features.

Please go to the slack.cloudfoundry.org and join the #CAB channel for previous and future discussions.

Talk (Zoom) to you all next week. I'll send one more reminder on this list and Slack.

Best,

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone

[1] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCOXiwhLs6gveTxAcduvDcW_xI/edit#heading=h.o44xhgvum2we

[2] https://github.com/cloudfoundry/cf-deployment

[3] https://github.com/cppforlife/turbulence-release

Hi, Idit,

Is there any updates on the concerns Daniel raised? Also, note comments in
proposals.

According to our process, when comments are not addressed, proposals become
stalled and then are subject to be removed from CF-extensions consideration.

Thanks in advance for addressing all comments.

Best,

Max

On Fri, Mar 24, 2017 at 4:33 AM Daniel Jones <
daniel.jones(a)engineerbetter.com> wrote:

Hi Idit,

Thanks for sending out the proposal, and thanks for giving your talk in
Santa Clara last year, which I attended and was excited by.

I've read the proposal and heard the talk, but I'll be frank - I still
don't get it. That may well be because I'm a simpleton who doesn't know
much about kernels, let alone unikernels, but if I don't ask some silly
questions I'll probably never know.


- Cloud Foundry aside, how does Unik go from receiving some app code
to know exactly which kernel features are needed for the application at run
time? This is the part that seems most magical to me.
- Where is the Unik daemon running - presumably somewhere of the
operators choice, mostly likely as a BOSH-deployed job?
- What happens if the Unik daemon dies - is it stateful? Will
unikernels continue to run and be manageable?
- Does the unikernel image get created at app staging time?
- Has there been any discussion about how to strategically implement
this alongside Diego, instead of the tactical solution of 'going through'
Diego?


I'm excited by the promise of unikernels - being able to cut out so much
bloat and indirection would be a massive win for efficiency if they usurped
containers as a unit of currency. I wonder how much CO2 emission we could
avoid by stripping abstraction away, instead of piling it on!

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On 16 March 2017 at 21:09, Michael Maximilien <mmaximilien(a)gmail.com>
wrote:

Thanks for this submission Idit and Dell/EMC.

I look forward to comments from community as we work this though the
CF-extensions process.

Best.

On Thu, Mar 16, 2017 at 1:25 PM Idit Levine <idit.levine(a)gmail.com> wrote:

One clarification, we propose it to the CF incubation program.

On Mar 16, 2017, at 3:59 PM, Idit Levine <idit.levine(a)gmail.com> wrote:

Hi all,

We at Dell EMC would like to propose to contribute project unik (

https://github.com/emc-advanced-dev/unik) and its integration with Cloud
Foundry (https://github.com/emc-advanced-dev/cf-unik-buildpack) to Cloud
Foundry community.

You can find the full official proposal at:

https://docs.google.com/document/d/1Q9GakKpm6DMniJpWB-fqhE13SSPaj4-3sOWZ-I5nVyA/edit?usp=sharing

We of course welcome input and feedback on the proposal via inline

commentary on the proposal document or directly to me.

Thanks,
Idit

--
dr.max Sent from my iPhone http://maximilien.org


--

dr.max Sent from my iPhone http://maximilien.org

Please see the following CVE (also available at
https://www.cloudfoundry.org/cve-2017-4970/).

To always be up to date with OSS Cloud Foundry CVE notices, please check
out the #security channel in the Cloud Foundry slack or subscribe to
https://www.cloudfoundry.org/category/security/feed/ in your favorite feed
reader.

Thanks,
Molly Crowther
CFF Security Team


April 10, 2017
CVE-2017-4970: Staticfile buildpack ignores basic authentication when
misconfiguredSeverity

High
Vendor

Cloud Foundry Foundation
Versions Affected

- cf-release v255
- Staticfile buildpack versions v1.4.0 – v1.4.3

Description

A regression introduced in the Staticfile buildpack causes the
Staticfile.auth configuration to be ignored when the Staticfile file is not
present in the application root. Applications containing a Staticfile.auth file
but not a Staticfile had their basic auth turned off when an operator
upgraded the Staticfile buildpack in the foundation to one of the
vulnerable versions. Note that Staticfile applications without a Staticfile are
technically misconfigured, and will not successfully detect unless the
Staticfile buildpack is explicitly specified.
Mitigation

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

- For existing deployments, upgrade the Staticfile Buildpack to v1.4.4
or later [1] and restage all applications that use the Staticfile Buildpack.
- Upgrade to cf-release v256 [2] when available.

References

- [1] https://github.com/cloudfoundry/staticfile-buildpack/releases
- [2] https://github.com/cloudfoundry/cf-release/releases

History

2017-04-10: Updated mitigation to apply to all apps using the Staticfile
buildpack instead of just apps with detection

2017-04-10: Initial vulnerability report published

Tip: You can plan a regular "bosh -n deploy --recreate" on each of your deployments, typically once per week. Run by Concourse, ou by a mere cron in your bosh-lite VM if it's just development.

Notice: Growing warden containers might indicate issues with growing log files. Missing log rotations in your BOSH releases or issues in your deployment settings that make error logs grow abnormally. You should question that too.

The Java Client does not yet cover all CF APIs (we’re at abut 400 of 550 total APIs) and we have not yet added the user administration operations. If you’d like to see them moved up the priority list, please open an issue in our GitHub repository[1] and we’ll incorporate that into our planning.


-Ben Hale
Cloud Foundry Java Experience


[1]: https://github.com/cloudfoundry/cf-java-client/issues

Hi All,

Ben and I will provide more details about this transition in the near
future.
The current plan is to provide online buildpack BOSH releases to replace
the offline buildpack BOSH releases, and to ship only online buildpacks in
cf-release.

Thanks,
Stephen

On Tue, Apr 11, 2017 at 11:20 AM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

The Cloud Foundry Foundation strives to keep Cloud Foundry both open
source and tailored to enterprise needs. Occasionally this is not
straightforward, and requires us to change the way we make Cloud Foundry
available to downstream distributions and open source users.

Currently, the buildpack project teams distribute the official Cloud
Foundry buildpacks on Github and bosh.io as pre-packaged bundles that
include all of their dependencies, such as language interpreters and
compilers. These offline buildpacks do not require an internet connection
when they are used to push Cloud Foundry apps. The project teams package
these offline buildpacks and make them available to encourage downstream
distributions to include the unmodified, official buildpacks wherever
possible. This promotes a consistent experience for developers across
different Cloud Foundry distributions.

Recently, the CFF has clarified its guidance to project teams with regard
to the distribution of proprietary software [1]. Since the buildpacks
include integrations with proprietary agent software, we need to change our
approach to buildpack distribution. We will soon cease to package and
distribute the offline buildpacks. Instead, we will publish instructions
for downstream consumers to package the offline buildpacks themselves.

Organizations who wish to distribute the offline buildpacks will be
responsible for any required licensing or export compliance obligations.
The buildpack project teams will publish and maintain a public list of
these integrations to make this process easier.

We still encourage downstream distributions to include the official
buildpacks with minimal changes where possible, and to work with the Cloud
Foundry Buildpacks team to integrate any changes they require upstream into
the official buildpacks.


I've CC'ed Ben Hale (Java Buildpack Lead) and Stephen Levine (Core
Buildpacks Lead), who can help answer any questions about this change.

[1] https://lists.cloudfoundry.org/archives/list/cf-dev@
lists.cloudfoundry.org/thread/PLV44TLOBQVS7UEHRPQFCXPJMVQIA3T3/


--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>

The Cloud Foundry Foundation strives to keep Cloud Foundry both open source
and tailored to enterprise needs. Occasionally this is not straightforward,
and requires us to change the way we make Cloud Foundry available to
downstream distributions and open source users.

Currently, the buildpack project teams distribute the official Cloud
Foundry buildpacks on Github and bosh.io as pre-packaged bundles that
include all of their dependencies, such as language interpreters and
compilers. These offline buildpacks do not require an internet connection
when they are used to push Cloud Foundry apps. The project teams package
these offline buildpacks and make them available to encourage downstream
distributions to include the unmodified, official buildpacks wherever
possible. This promotes a consistent experience for developers across
different Cloud Foundry distributions.

Recently, the CFF has clarified its guidance to project teams with regard
to the distribution of proprietary software [1]. Since the buildpacks
include integrations with proprietary agent software, we need to change our
approach to buildpack distribution. We will soon cease to package and
distribute the offline buildpacks. Instead, we will publish instructions
for downstream consumers to package the offline buildpacks themselves.

Organizations who wish to distribute the offline buildpacks will be
responsible for any required licensing or export compliance obligations.
The buildpack project teams will publish and maintain a public list of
these integrations to make this process easier.

We still encourage downstream distributions to include the official
buildpacks with minimal changes where possible, and to work with the Cloud
Foundry Buildpacks team to integrate any changes they require upstream into
the official buildpacks.


I've CC'ed Ben Hale (Java Buildpack Lead) and Stephen Levine (Core
Buildpacks Lead), who can help answer any questions about this change.

[1]
https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/thread/PLV44TLOBQVS7UEHRPQFCXPJMVQIA3T3/


--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

All,

The following email is being shared with cf-dev@ in the interests of
transparency into the project for the larger community. There will be a
follow up email related to the impact of this on buildpacks.

Guidance to CFF Project Teams - Handling of Proprietary Software
IntegrationsCloud Foundry FoundationBackground

Cloudfoundry.org Foundation, Inc. (CFF) is a United States based 501(c)(6)
nonprofit organization. The Foundation’s purpose is to support the growth
and adoption of Cloud Foundry as the leading application platform for
cloud computing globally.

Due to the nature of the Cloud Foundry software, the CFF actively
encourages the integration of relevant and complementary technologies, both
open source and proprietary. These integrations provide valuable
functionality for end users of Cloud Foundry, both direct users of the open
source and users of commercial distributions / services derived from the
CFF’s open source software.

As a U.S. based organization, the CFF is required to comply with relevant
U.S. regulations and laws related to the export of software from the U.S..
In particular, the CFF’s software is collectively classified as ECCN 5D002
due to the inclusion of encryption technologies within the platform. The
CFF exports its software under the terms of the TSU exception in EAR
section 740.13(e), which applies to software containing or designed for use
with encryption software that is publicly available as open source, and
have been registered by the CFF with the U.S. government under this TSU
exception. More information can be found here:
https://www.cloudfoundry.org/exports/
Software Distribution

In order to comply with the requirements in the TSU exception, the CFF and
it’s projects should only distribute open source software.

This includes both source code and compiled versions of that software. The
open source software need not be a project of the CFF (it may be sourced
from other open source projects). In cases of compiled software, there must
be a direct correlation between the binary and the open source code that it
is created from.

Distribution of software should be considered any of the following:

1.

Distribution from CFF owned GitHub organizational repositories,
including, but not limited to, source repositories and release artifacts.
This applies to the following GitHub organizations:
1.

https://github.com/cloudfoundry
2.

https://github.com/cloudfoundry-incubator
3.

https://github.com/cloudfoundry-attic
4.

https://github.com/cloudfoundry-samples
5.

https://github.com/openservicebrokerapi
2.

Distribution of software via any cloudfoundry.org URL, regardless of the
infrastructure that it is hosted on.
3.

Distribution of software via bosh.io
4.

Distribution from any other location directly associated with any CFF
project team


This does not apply to locations not owned by, or the responsibility of,
the Cloud Foundry Foundation or its projects. This includes commercial
vendor distribution locations, which are not the responsibility of the CFF.
Guidance on Handling Proprietary Software Integrations

As stated earlier, the CFF actively encourages the integration of any type
of relevant and complementary software into the CFF’s software. This
includes proprietary and closed source software products.

However, CFF project teams must be aware of the distribution restrictions
and design the integrations in a way that avoids the CFF distribution of
proprietary software.

Code written to support the integration of proprietary software is
encouraged (where appropriate), and may be hosted within the CFF project
repositories and distributed via CFF distribution channels. As always, all
source code included in CFF projects must comply with the relevant CFF
policies on licensing, including the Intellectual Property Policy
<https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_IP_Policy.pdf>
and the Development Operations Policy
<https://www.cloudfoundry.org/wp-content/uploads/2017/01/CFF_Development_Operations_Policy.pdf>
.

Distribution of proprietary software should be left to either the
organization from which the software is sourced (the vendor) or be the
responsibility of Cloud Foundry downstream distributions / service
providers.

Project teams are also asked to review existing integrations in order to
ensure compliance.
Getting Help

If any project team has questions around this guidance, CFF staff will
either directly answer the question or facilitate a conversation with the
appropriate legal counsel.

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

the space name and space id should be available in/via the VCAP_APPLICATION
environment variable. / eitan

On Tue, Apr 11, 2017 at 5:46 AM, CF_genn <CF_subscription(a)streber24.de>
wrote:

Hi CF-DEV,
I have a Java app deployed and running. Is it possible to find out from the
application
- in what org / space it is running?
- can it find out its own name? (as shown in "cf apps")

Thank you!





--
View this message in context: http://cf-dev.70369.x6.nabble.
com/Java-How-to-find-out-user-org-application-tp6729.html
Sent from the CF Dev mailing list archive at Nabble.com.

Hi CF-DEV,
I have a Java app deployed and running. Is it possible to find out from the
application
- in what org / space it is running?
- can it find out its own name? (as shown in "cf apps")

Thank you!





--
View this message in context: http://cf-dev.70369.x6.nabble.com/Java-How-to-find-out-user-org-application-tp6729.html
Sent from the CF Dev mailing list archive at Nabble.com.

I am trying to receive packets from outside to the application deployed on CF. Below is the code link, which I deployed on the CF
https://github.com/aerondeepak/FireDetect/blob/master/workspace123/Web2210_1/src/com/srk/pkg/MsgReader.java

Now the problem is that, sometime it works and sometimes it start giving 502 error code. Logs as follow

2017-04-10T07:42:26.10-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:26.099+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35102" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"60e48bc9-79b9-4ee0-6d4b-8c4e51e374e4" response_time:0.004780496 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:42:26.89-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:26.891+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35112" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"5201afed-8a50-4f3e-59e6-d2bb4a6bf946" response_time:0.002842261 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:42:27.56-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:27.555+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35120" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"1a999304-4674-4421-7667-bf72b8d673e8" response_time:0.00615609 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:42:28.14-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:28.137+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35128" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"2c2297a7-a21d-4000-55b6-e3df98c7a837" response_time:0.002684419 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:42:28.99-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:28.994+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35146" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"6ce25e45-31c0-4c0e-4389-4f2a8237db59" response_time:0.004043811 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:42:29.79-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:29.796+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35158" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"b88470fd-388c-46aa-63aa-86f22d7f1ac2" response_time:0.001441524 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:42:30.64-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:42:30.644+0000] "GET / HTTP/1.1" 200 0 108 "-" "curl/7.47.0" "10.244.0.34:35170" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"a591f0c4-b80e-48a6-4599-c6763f746e02" response_time:0.004055264 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:44:38.30-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-10T11:44:23.301+0000] "GET / HTTP/1.1" 502 0 67 "-" "curl/7.47.0" "10.244.0.34:36668" "10.244.16.5:60036" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"a9cf41d3-46ca-4af4-7e5f-3be0bd004ea2" response_time:15.004394412 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-10T07:44:55.71-0400 [API/0] OUT Updated app with guid 804c0c7c-3d3a-4e91-b0bc-0bced8a7d907 ({"state"=>"STOPPED"})
2017-04-10T07:44:55.71-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Pausing ProtocolHandler ["http-nio-8080"]
2017-04-10T07:44:55.72-0400 [CELL/0] OUT Exit status 0

Thanks

Woot sauce CF CLI!

On Fri, Apr 7, 2017 at 2:01 PM Mark Carlson - Conneva, Inc. <
m.carlson(a)conneva.com> wrote:

Great work, team CF CLI!

We've updated the ECS Team CF CLI quick reference guide [1] to include the
new Isolation Segments commands. Also, the latest version of the "cf top"
CLI plugin [2] will display cells grouped by isolation segments, if present.

[1] CF CLI Quick Ref guide for v6.26.0:
https://s3-us-west-2.amazonaws.com/ecsteam-cloudfoundry/cf-quickref-6.26.0-1.0.40.pdf

[2] cf top plugin v0.8.1:
https://github.com/ECSTeam/cloudfoundry-top-plugin

Mark Carlson, ECS Team

On Thu, Apr 6, 2017 at 7:46 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

The CF CLI team just cut 6.26.0.

Deb, yum and Homebrew repos have been updated; binaries, installers and
link to release notes are available at:



https://github.com/cloudfoundry/cli#downloads
Isolation segments

This release introduces commands to manage isolation segments, enabling
one to run applications in a dedicated resource pool.
The new commands require a target CF release of v254 (CC API v3.11.0)
onwards.

Refer to the documentation
<http://docs.cloudfoundry.org/adminguide/isolation-segments.html> for
details of this feature.
Fixed regressions

- create-buildpack and update-buildpack did not accept a URL to a
buildpack in cf CLI v6.25.0. (#1085
<https://github.com/cloudfoundry/cli/issues/1085>)
- ssh failed when transferring more than 2GB since cf CLI v6.24.0. (
#1098 <https://github.com/cloudfoundry/cli/issues/1098>)

Refactored commands

We are in the process of creating a more consistent user experience; our
goal is to standardize UI output.
For example, warnings and errors will consistently be outputted to stderr
instead of stdout and English table and key-value headers displayed in
lowercase.
As we iterate through the list of commands, we are also focusing on
improving performance and stability.
Please review your scripts if they depend on the output of these commands.

List of improved commands in this release:

- org
- space
- app
- start
- log
- bind-security-group

Updated commands

- start now displays a more detailed error message when staging fails.
- delete-org and delete-shared-domain now display in more detail what
else gets deleted in their confirmation messages. (#1082
<https://github.com/cloudfoundry/cli/issues/1082>)
- delete-user now displays a better error message when several users
of the same name (from different origins) exist. (#1097
<https://github.com/cloudfoundry/cli/issues/1097>)

New & updated community plugins

- cf-icd-plugin v0.0.11: https://github.com/IBM/cf-icd-plugin
- sync v1.1.1: https://github.com/orange-cloudfoundry/cf-plugin-sync
- top v0.8.1: https://github.com/ECSTeam/cloudfoundry-top-plugin
- Firehose Plugin v0.12.0:
http://github.com/cloudfoundry-community/firehose-plugin
- cflocal v0.8.0: https://github.com/sclevine/cflocal
- java-plugin v1.0.0: https://github.com/SAP/cf-cli-java-plugin
- blue-green-deploy v1.2.0:
https://github.com/bluemixgaragelondon/cf-blue-green-deploy
- buildpack-usage v1.0.4: https://github.com/ECSTeam/buildpack-usage

Enjoy!

Regards,

Dies Koper
Cloud Foundry Product Manager - CLI