Date   

Re: CF CLI v6.26.0 Released Today

Juan Pablo Genovese
 

Fantastic work! Thank you!

2017-04-07 17:35 GMT-03:00 Dieu Cao <dcao(a)pivotal.io>:

Great release! Super excited about this release with Isolation Segment
support!

On Thu, Apr 6, 2017 at 6: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/bluemixgara
gelondon/cf-blue-green-deploy
- buildpack-usage v1.0.4: https://github.com/ECSTeam/buildpack-usage

Enjoy!

Regards,

Dies Koper
Cloud Foundry Product Manager - CLI




--
Mis mejores deseos,
Best wishes,
Meilleurs vœux,

Juan Pablo
------------------------------------------------------
http://www.jpgenovese.com


Re: CF CLI v6.26.0 Released Today

Dieu Cao <dcao@...>
 

Great release! Super excited about this release with Isolation Segment
support!

On Thu, Apr 6, 2017 at 6: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
<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





Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Deepak Arn <arn.deepak1@...>
 

I have created the new security group

cf security-group private-network
Getting info for security group private-network as admin
OK

Name private-network
Rules
[
{
"destination": "10.0.0.0-10.255.255.255",
"ports": "443",
"protocol": "tcp"
},
{
"destination": "172.16.0.0-172.31.255.255",
"ports": "9003",
"protocol": "tcp"
},
{
"destination": "192.168.0.0-192.168.255.255",
"ports": "443",
"protocol": "tcp"
}
]

Organization Space
#0 system Inter-PC

Still in the logs its not giving Connection Refused error, but still 502 response code, please see the logs below:

2017-04-07T10:02:01.85-0400 [CELL/0] OUT Container became healthy
2017-04-07T10:03:38.63-0400 [CELL/0] ERR Failed to destroy container
2017-04-07T10:05:56.79-0400 [API/0] OUT Updated app with guid 804c0c7c-3d3a-4e91-b0bc-0bced8a7d907 ({"state"=>"STOPPED"})
2017-04-07T10:05:56.80-0400 [CELL/0] OUT Exit status 0
2017-04-07T10:05:56.80-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Pausing ProtocolHandler ["http-nio-8080"]
2017-04-07T10:05:56.86-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.core.StandardService INFO Stopping service Catalina
2017-04-07T10:05:56.91-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Stopping ProtocolHandler ["http-nio-8080"]
2017-04-07T10:05:56.92-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Destroying ProtocolHandler ["http-nio-8080"]
2017-04-07T10:05:56.93-0400 [APP/PROC/WEB/0]OUT Exit status 143
2017-04-07T10:05:56.93-0400 [CELL/0] OUT Destroying container
2017-04-07T10:05:57.20-0400 [CELL/0] OUT Successfully destroyed container
2017-04-07T10:06:12.10-0400 [API/0] OUT Updated app with guid 804c0c7c-3d3a-4e91-b0bc-0bced8a7d907 ({"state"=>"STARTED"})
2017-04-07T10:06:12.13-0400 [CELL/0] OUT Creating container
2017-04-07T10:06:12.45-0400 [CELL/0] OUT Successfully created container
2017-04-07T10:06:14.67-0400 [CELL/0] OUT Starting health monitoring of container
2017-04-07T10:06:15.52-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Initializing ProtocolHandler ["http-nio-8080"]
2017-04-07T10:06:15.53-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.startup.Catalina INFO Initialization processed in 498 ms
2017-04-07T10:06:15.54-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.core.StandardService INFO Starting service Catalina
2017-04-07T10:06:15.54-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.core.StandardEngine INFO Starting Servlet Engine: Apache Tomcat/8.0.43
2017-04-07T10:06:15.56-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.startup.HostConfig INFO Deploying web application directory /home/vcap/app/.java-buildpack/tomcat/webapps/ROOT
2017-04-07T10:06:16.03-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.jasper.servlet.TldScanner INFO At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
2017-04-07T10:06:16.13-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.startup.HostConfig INFO Deployment of web application directory /home/vcap/app/.java-buildpack/tomcat/webapps/ROOT has finished in 568 ms
2017-04-07T10:06:16.13-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.coyote.http11.Http11NioProtocol INFO Starting ProtocolHandler ["http-nio-8080"]
2017-04-07T10:06:16.15-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.tomcat.util.net.NioSelectorPool INFO Using a shared selector for servlet write/read
2017-04-07T10:06:16.16-0400 [APP/PROC/WEB/0]OUT [CONTAINER] org.apache.catalina.startup.Catalina INFO Server startup in 632 ms
2017-04-07T10:06:16.76-0400 [CELL/0] OUT Container became healthy
2017-04-07T10:07:57.36-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-07T14:07:42.366+0000] "GET / HTTP/1.1" 502 0 67 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" "10.244.0.34:60202" "10.244.16.5:60024" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"419c5248-9c18-4c4f-4f55-96533d32c5c3" response_time:15.002796164 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-07T10:08:23.84-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-07T14:08:08.837+0000] "GET / HTTP/1.1" 502 0 67 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" "10.244.0.34:60202" "10.244.16.5:60024" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"43e42e24-f2db-487a-62f4-b9fc3b4524d0" response_time:15.00634438 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"
2017-04-07T10:09:57.06-0400 [RTR/0] OUT firedetect.bosh-lite.com - [2017-04-07T14:09:42.060+0000] "GET / HTTP/1.1" 502 0 67 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0" "10.244.0.34:60202" "10.244.16.5:60024" x_forwarded_for:"192.168.50.1, 10.244.0.34" x_forwarded_proto:"http" vcap_request_id:"97396a4d-7dff-461e-7cc8-515a43e7ed2a" response_time:15.003535923 app_id:"804c0c7c-3d3a-4e91-b0bc-0bced8a7d907" app_index:"0"


Re: What are the process type in Procfile supported by CloudFoundry?

Dieu Cao <dcao@...>
 

--health-check-type none is misleading and the none value is deprecated in
favor of the type 'process'
The none/process health check types will check if the process is alive and
instance is restarted if the process dies.

From the cf push help

--health-check-type, -u Application health check type (Default:
'port', 'none' accepted for 'process', 'http' implies endpoint '/')

-Dieu

On Fri, Apr 7, 2017 at 12:10 AM, Sze Siong Teo <szesiong(a)gmail.com> wrote:

Hi Zach, thanks for the feedback.

Nevertheless, using "--health-check-type none" option sounds like a bit of
hackish workaround?

Is CF going to support monitoring for this kind of processes like
conventional cron? Let's say if the invoked target process/script return a
non-zero exit code and the stdout can be sent as notification via email or
something similar?

My main concern is without health check, then we will be having zero
visibility whether a job is executed properly or failed.

Thanks.


Any guides on clearing enormous bosh cache data?

Sze Siong Teo <szesiong@...>
 

Hi, does anyone know what is the right approach to remove unnecessary cache in these places?

I've already removed unused deployments and releases but the size in the following folders are still quite large and growing pretty fast.

/var/vcap/store/warden_cpi
/var/vcap/store/blob_store
/var/vcap/data/garden/aufs_graph

Any tips?


Re: What are the process type in Procfile supported by CloudFoundry?

Sze Siong Teo <szesiong@...>
 

Hi Zach, thanks for the feedback.

Nevertheless, using "--health-check-type none" option sounds like a bit of hackish workaround?

Is CF going to support monitoring for this kind of processes like conventional cron? Let's say if the invoked target process/script return a non-zero exit code and the stdout can be sent as notification via email or something similar?

My main concern is without health check, then we will be having zero visibility whether a job is executed properly or failed.

Thanks.


Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Sze Siong Teo <szesiong@...>
 

For updating ASG, you don't need to run 'bosh deploy'
https://docs.cloudfoundry.org/adminguide/app-sec-groups.html#updating-groups

You can use this tool to generate the rules from yaml
https://github.com/cloudfoundry-incubator/asg-creator


CF CLI v6.26.0 Released Today

Koper, Dies <diesk@...>
 

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


Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Deepak Arn <arn.deepak1@...>
 

Hi, I have changed the range of security group for public_networks in cf-release/bosh-lite/deployments/cf.yml
- name: public_networks
rules:
- destination: 0.0.0.0-9.255.255.255
protocol: all
- destination: 10.0.0.0-169.253.255.255
protocol: all
- destination: 169.255.0.0-172.15.255.255
protocol: all
- destination: 172.32.0.0-192.168.255.255
protocol: all
- destination: 192.169.0.0-255.255.255.255
protocol: all

Then to reflect the changes in the deployment, follow the below steps:
cf-release$ bosh deployment ~/workspace/cf-release/bosh-lite/deployments/cf.yml
Deployment set to '/home/deepak/workspace/cf-release/bosh-lite/deployments/cf.yml'
deepak(a)deepak-OptiPlex-7010:~/workspace/cf-release$ bosh deploy

but when I am checking the security group of public_networks using cf_cli, the changes are not refected

cf-release$ cf security-group public_networks
Getting info for security group public_networks as admin
OK

Name public_networks
Rules
[
{
"destination": "0.0.0.0-9.255.255.255",
"protocol": "all"
},
{
"destination": "11.0.0.0-169.253.255.255",
"protocol": "all"
},
{
"destination": "169.255.0.0-172.15.255.255",
"protocol": "all"
},
{
"destination": "172.32.0.0-192.167.255.255",
"protocol": "all"
},
{
"destination": "192.169.0.0-255.255.255.255",
"protocol": "all"
}
]

Organization Space
#0 system Inter-PC

Please correct, if I am doing anything wrong

Thanks


Re: What are the process type in Procfile supported by CloudFoundry?

Zach Robinson
 

Yes, that is supported using the "--health-check-type none" option for cf
push that Leandro mentioned.

-Zach

On Thu, Apr 6, 2017 at 5:00 AM Sze Siong Teo <szesiong(a)gmail.com> wrote:

Hi Zach,

I saw this "Experimental - Applications consisting of several processes
via a Procfile" but is this a worker process feature for web app to achieve
multi-process backend?

What I'm looking for is to have CF support non-web long running process or
cron jobs. Is that in the roadmap of CF development?

Thanks.


New Required cc_uploader Server Certs

Timothy Hausler
 

CAPI has been continuing the work to secure internal traffic with CAPI VMs
[1]. Next on the list of jobs that now need certs is CC-Uploader.
CC-Uploader's purpose is to manage blobstore upload requests from Diego,
mostly droplets and build artifacts. In an upcoming CAPI release (1.26.0),
the properties below will be required for the cc-uploader job. There is no
harm in filling in these properties now. * capi.cc_uploader.ca_cert *
capi.cc_uploader.server_cert * capi.cc_uploader.server_key If you're using
manifest generation from diego-release from the example AWS or bosh-lite
manifests, the certs should be generated automatically from upcoming PRs
[2].

Otherwise, please see the following doc for TLS generation:
https://github.com/cloudfoundry/capi-release/blob/develop/docs/tls-configuration.md.
Diego cert generation scripts have been updated include generation of the
new cc-uploader certs that you need. If you have any questions or hit any
speed bumps, please reach out to us on slack in the #capi channel [3].

Best,
Tim Hausler && Jen Spinney, CAPI team members [1]
https://www.pivotaltracker.com/epic/show/2541685 [2]
https://github.com/cloudfoundry/diego-release/pull/292 &
https://github.com/cloudfoundry/cf-deployment/pull/110 [3]
https://cloudfoundry.slack.com/messages/capi/


Re: Proposal for named service bindings

Nikolay Valchev
 

This is a real problem that we face in some of our apps as well. We’ve addressed it with the app environment variable configuration to tell the purpose of each service instance. Such approach works, but the solution in this proposal is more elegant. The only thing that bothers me is that in most cases the named binding might not be needed and thus should be better an optional CLI argument, which if missing might be populated by the service name as default value.

Nikolay

From: Mike Youngstrom <youngm(a)gmail.com>
Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Date: Saturday, April 1, 2017 at 18:45
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: [cf-dev] Re: Re: Re: Re: Re: Re: Proposal for named service bindings

The proposal still has my vote FWIW. :)

Mike

On Sat, Apr 1, 2017 at 7:11 AM, Peter Dotchev <dotchev(a)gmail.com<mailto:dotchev(a)gmail.com>> wrote:
The approach with tags has some issues too:
- User-provided services have no tags
- Ambiguous. Tags are not unique so it is possible that the same tag appears in multiple service instances bound to the same app
- It is possible that different apps put different meaning in the same tag. This can lead to problems if a service instance with this tag is bound to these apps.

Generally service bindings act as input to applications, similar to function arguments. Usually we want to name each input so it has a clear purpose.

So, please consider again the proposal to add name on service bindings.


On Wed, Mar 15, 2017 at 9:06 AM, Peter Dotchev <dotchev(a)gmail.com<mailto:dotchev(a)gmail.com>> wrote:
Ok, this might work.
Will try it.

Thanks for the update.

On Wed, Mar 15, 2017 at 12:54 AM, Koper, Dies <diesk(a)fast.au.fujitsu.com<mailto:diesk(a)fast.au.fujitsu.com>> wrote:
I spot a CLI question?

But if you have created a service instance and later you want to bind it to a new app, can you add the tag expected by that app to the existing service instance?
`cf update-service mydb -t "list, of, tags"`
http://cli.cloudfoundry.org/en-US/cf/update-service.html

Regards,
Dies Koper
Cloud Foundry Product Manager - CLI


From: Peter Dotchev [mailto:dotchev(a)gmail.com<mailto:dotchev(a)gmail.com>]
Sent: Tuesday, March 14, 2017 6:17 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: [cf-dev] Re: Re: Re: Proposal for named service bindings

Yes, tags at service instance level could work.
But if you have created a service instance and later you want to bind it to a new app, can you add the tag expected by that app to the existing service instance?
Also tags do not identify a service instance uniquely, so it is still possible that an app is bound to multiple instances with the same tag.
I have seen many apps that scan VCAP_SERVICES for a service with specific properties and pick the first match. This is error prone as there could be multiple matches.

So I think binding names would be more explicit and tags seem more like a workaround.


On Mon, Mar 13, 2017 at 9:22 PM, Greg Cobb <gcobb(a)pivotal.io<mailto:gcobb(a)pivotal.io>> wrote:
One can supply arbitrary tags for service instances: https://apidocs.cloudfoundry.org/253/service_instances/creating_a_service_instance.html. This is not at the binding level, but you could tag your instances as "secure" and filter on that. Does this help your use case?

On Sun, Mar 12, 2017 at 5:04 PM, Mike Youngstrom <youngm(a)gmail.com<mailto:youngm(a)gmail.com>> wrote:
This is a great idea. Today to get around this issue my org names our service instances with a #value at the end and we use custom VCAP_SERVICES client libraries to ignore anything after the #. That allows us to have a service named oracle-db#dev and oracle-db#test both be found in configuration with the name "oracle-db". This proposal would fix that issue for my org.

Mike

On Sun, Mar 12, 2017 at 4:02 PM, Peter Dotchev <dotchev(a)gmail.com<mailto:dotchev(a)gmail.com>> wrote:
Hi,

Selecting the right service binding from application code in Cloud Foundry is often ambiguous and error prone. To address this, I propose to introduce a service binding name.

The proposal is described in details here
https://github.com/dotchev/cf-named-binding

Looking forward to your comments.

Best regards,
Peter


Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Sze Siong Teo <szesiong@...>
 

By default, bosh-lite is configured to use ASG if I'm not wrong as I couldn't get "cf allow-access ..." as a registered command.

You will need to configure the network to allow proper egress to your host machine or virtualbox IP range through https://docs.cloudfoundry.org/adminguide/app-sec-groups.html


Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Deepak Arn <arn.deepak1@...>
 

I have installed the vagrant and didn't make any change in the network configuration by myself.
$./bin/add-route
+ old_ips=10.244.0.0/19
+ ips=10.244.0.0/16
+ gw=192.168.50.4
+ echo 'Adding the following route entry to your local route table to enable direct container access: 10.244.0.0/16 via 192.168.50.4. Your sudo password may be required.'
++ uname
+ '[' Linux = Darwin ']'
++ uname
+ '[' Linux = Linux ']'
+ type route
+ sudo route del -net 10.244.0.0/19 gw 192.168.50.4
SIOCDELRT: No such process
+ sudo route add -net 10.244.0.0/16 gw 192.168.50.4
SIOCADDRT: File exists

I tried to ping the host machine and virtual box(where bosh-lite is running) from inside the application container(cf ssh [App_Name]), the destination port is unreachable
vcap(a)6e223f67-0574-4c32-7d14-615707291a59:~$ ping 192.168.50.1
PING 192.168.50.1 (192.168.50.1) 56(84) bytes of data.
From 10.255.47.1 icmp_seq=1 Destination Port Unreachable
From 10.255.47.1 icmp_seq=2 Destination Port Unreachable
From 10.255.47.1 icmp_seq=3 Destination Port Unreachable

So far, all vms' are running(bosh vms).
If there is a need to config network config from vagrant or virtual box, Please suggest, what changes I need to do to fix this.

Thanks,


Re: What are the process type in Procfile supported by CloudFoundry?

Sze Siong Teo <szesiong@...>
 

Hi Zach,

I saw this "Experimental - Applications consisting of several processes via a Procfile" but is this a worker process feature for web app to achieve multi-process backend?

What I'm looking for is to have CF support non-web long running process or cron jobs. Is that in the roadmap of CF development?

Thanks.


Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Sze Siong Teo <szesiong@...>
 

AFAIK, all *.bosh-lite.com resolves to 10.244.0.34

Did you setup via vagrant or manually? There scripts within the VM itself that will add iptables rules to route traffic to proper interface for 10.244.0.x if I remember correctly. My bosh-lite.com setup is a bit different due to some reasons that I can't use vagrant on my machine but I would suggest vagrant for simplicity.

I don't remember what's the subnet created by vagrant for the VM, but you might need to use 10.244.0.34 if it's not using the 192.168.x.x network.

Also, make sure you are able to ping the containers in bosh-lite. In the VM itself, perform a 'bosh vms' to check all status of warden containers, if some not responding use 'bosh cck' to repair them (usually happens after your VM restart).


Re: Incubation Proposal - haproxy-boshrelease

Dieu Cao <dcao@...>
 

I'm pleased to announce that haproxy-boshrelease has been accepted for
incubation into the Runtime PMC!
Geoff Franks will be serving as the project lead.

Will work with Geoff on the logistics.

-Dieu
Runtime PMC Lead

On Fri, Mar 31, 2017 at 10:23 AM, Krannich, Bernd <bernd.krannich(a)sap.com>
wrote:

Same here. From the SAP side, we are also big fans of the
haproxy-boshrelease and very much support this proposal.



Regards,

Bernd



*Bernd Krannich*

SAP Cloud Platform

*SAP SE*

Dietmar-Hopp-Allee 16, 69190 Walldorf, Germany



Pflichtangaben/Mandatory Disclosure Statement: www.sap.com/impressum
<http://www.sap.com/company/legal/impressum.epx/>



Diese E-Mail kann Betriebs- oder Geschäftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail irrtümlich
erhalten haben, ist Ihnen eine Kenntnisnahme des Inhalts, eine
Vervielfältigung oder Weitergabe der E-Mail ausdrücklich untersagt. Bitte
benachrichtigen Sie uns und vernichten Sie die empfangene E-Mail. Vielen
Dank.



This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail in
error, you are hereby notified that any review, copying, or distribution of
it is strictly prohibited. Please inform us immediately and destroy the
original transmittal. Thank you for your cooperation.





*From: *Gwenn Etourneau <getourneau(a)pivotal.io>
*Reply-To: *"Discussions about Cloud Foundry projects and the system
overall." <cf-dev(a)lists.cloudfoundry.org>
*Date: *Friday, 31. March 2017 at 02:18
*To: *"Discussions about Cloud Foundry projects and the system overall." <
cf-dev(a)lists.cloudfoundry.org>
*Subject: *[cf-dev] Re: Re: Re: Incubation Proposal - haproxy-boshrelease



Nice ! Hope this release will be able to make it.



On Fri, Mar 31, 2017 at 1:48 AM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

Outstanding! This is a pretty important component of so many deployments.
Really happy to see the S&W version come into the fold.

On Thu, Mar 30, 2017 at 6:46 PM Dieu Cao <dcao(a)pivotal.io> wrote:

Very excited to start the process for incubation to the Runtime PMC for
this project!

Will reach out to you with details on bringing this forth for a vote at
the next Runtime PMC meeting.



-Dieu



Runtime PMC Lead



On Thu, Mar 30, 2017 at 6:30 AM, Geoff Franks <geoff(a)starkandwayne.com>
wrote:

Hey All,



We would like to propose https://github.com/cloudfoundry-community/
haproxy-boshrelease for the incubation process. It would be a good fit
for the Runtime PMC to get a supportable HAProxy solution with support for
SNI, internal-domain-restrictions, WSS support, and more. It's been
maintained for the past couple years by Stark & Wayne, with some awesome
contributions from Orange, Hybris, Pivotal and more!



--

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



Increasing Routing availability in the event of failure with route registration

Shannon Coen
 

The Routing and Diego teams are starting to think about how to avoid
pruning routes after two minutes when there's a failure with NATS or a
network partition between Emitters, NATS, and Routers, while stilly
minimizing the probability of misrouting.

We welcome your feedback as comments in this document:
https://docs.google.com/document/d/1zkPVGNnBX18rWdOpinIEtRxte3kwpVhIyS9_WM3ITqM/edit#

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.

Deepak Arn <arn.deepak1@...>
 

Hi Teo,

Thanks for the reply.
I have changed the code, Now application code is not handling any thread by itself
Now getting the error
502 Bad Gateway: Registered endpoint failed to handle the request.
As per my understanding, it's some networking issue, which is giving Connection Refused every time when application on cloud foundry trying to make connection from outside cloud foundry. As cf_release is running locally on virtual box and other application also running on same system. So it won't give any network error. I also tried with sample application(code snippet is below), still giving Connection refused error. It may be the case, cloud foundry requires some configuration to allow egress or ingress. Could you please suggest

2017-04-05T16:14:01.08-0400 [APP/PROC/WEB/0]ERR sf(a)192.168.188.131:8080 died - exiting (java.net.ConnectException: Connection refused (Connection refused))


String url = "http://192.168.144.39:8081/Servlet2/?Temp=1";
URL siteURL = new URL(url);
HttpURLConnection connection = (HttpURLConnection) siteURL.openConnection();
connection.setRequestMethod("GET");
connection.connect();
int code = connection.getResponseCode();
if (code == 200) {
result = "Green";
out.println(output);
}


Thanks,


Re: What are the process type in Procfile supported by CloudFoundry?

Zach Robinson
 

Support for Procfiles is currently being added to Cloud Foundry.

It is part of the V3 API, which are experimental at the moment, docs here: http://v3-apidocs.cloudfoundry.org/

You can follow progress towards V3 GA release in our tracker project here: https://www.pivotaltracker.com/story/show/135301677

-Zach

2761 - 2780 of 9425