|
Java: How to find out user, org, application
CF_genn <CF_subscription@...>
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. |
|
|
|
Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.
Deepak Arn <arn.deepak1@...>
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 |
|
|
|
Re: CF CLI v6.26.0 Released Today
Jim Park
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! |
|
|
|
Removing UDP Endpoint from Doppler
In order to enforce that all traffic is encrypted and delivered over gRPC going forward the Loggregator team will be removing the UDP endpoint and associated properties from Doppler. This change also allows us to eliminate a sharedSecret from metron[1]. We have been keeping this around to ensure a highly available upgrade path for previous versions and have now reached a point to remove this.
This API is not a supported ingress point into Loggregator but it is possible that experimental features have utilized it as an alternative to including a metron agent. If you have questions about this work or are interested in tracking the change please see this Pivotal Tracker story [2] or reach out to us on Slack[3]. [1] - Github Pull request to remove shared secret - https://github.com/cloudfoundry/loggregator/pull/244 [2] - Pivotal Tracker Story - https://www.pivotaltracker.com/story/show/143056665 [3] - Loggregator Slack Channel - https://cloudfoundry.slack.com/messages/C02HCCXV5 |
|
|
|
Re: 404 Not Found: Requested route ('firedetect.bosh-lite.com') does not exist.
Sze Siong Teo <szesiong@...>
What is the hostname you are trying to access from outside? And are you getting connection refused or 502 bad gateway?
If connection refused then it is network routing issue if 502 it is very likely due to some of the containers running your app stucked or need to restart because nginx couldn't connect to it. Also, ensure the hostname you are hitting is the same as listed the your app listed in 'cf apps' URLs column. |
|
|
|
Re: What are the process type in Procfile supported by CloudFoundry?
Sze Siong Teo <szesiong@...>
Thanks
|
|
|
|
Re: CF CLI v6.26.0 Released Today
Mark Carlson - Conneva, Inc. <m.carlson@...>
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. |
|
|
|
Re: CF CLI v6.26.0 Released Today
Juan Pablo Genovese
Fantastic work! Thank you!
toggle quoted message
Show quoted text
2017-04-07 17:35 GMT-03:00 Dieu Cao <dcao(a)pivotal.io>: Great release! Super excited about this release with Isolation Segment --
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. |
|
|
|
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
toggle quoted message
Show quoted text
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. |
|
|
|
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
toggle quoted message
Show quoted text
push that Leandro mentioned. -Zach On Thu, Apr 6, 2017 at 5:00 AM Sze Siong Teo <szesiong(a)gmail.com> wrote:
Hi Zach, |
|
|
|
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.
toggle quoted message
Show quoted text
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 |
|
|