Date   

Re: URL of a Service Instance

Dieu Cao <dcao@...>
 

For 1. At minimum, you'll need to look at what application security groups
apply to your app, and have your admin add a new application security group
for that private ip range and bind it to your app's space or add it to the
set of running application security groups if all orgs on your cf should be
able to connect to services that your broker provisioned.

Beyond that, your network may have other restrictions on traffic coming
from your cloud foundry applications to your private ip addresses and
you'll need to talk to your network administrator about how to resolve that.

For 2. Only you know what service you have provisioned, how it was
provisioned and where to look at logs for it. If it was a bosh deployed
service, you should be able to bosh ssh onto the vm.

Dieu
CF CAPI PM

On Monday, December 28, 2015, Rahul Gupta <wildnez(a)gmail.com> wrote:

Hi Dieu,

I figured that out and did the following:
1. Created an instance of caching server. As soon as the instance gets
created, I extract the hostname and InetAddress of this instance and stores
in credentials upon bind request. For example, the host and InetAddress
returned is 10.254.0.58.
2. When an app is bound to the service, the credentials do show up in
VCAP_SERVICES.
3. I then use the IP address returned in credentials on bind response, in
the application to initiate a connection with the caching server. At this
point, the app refuses to find any server running at that IP.

So 2 questions:
1. The IP address returned is a private IP. Can an application running on
Cloud Foundry connect with a service instance through private IP address?
If yes, then do I need to do something special to enable this communication
through private IP?
2. How and where do I see the logs of caching server which was created by
the broker in createServiceInstance?

Thanks,
Rahul


Codependent step exited issue

Sam Dai
 

I have a java application, I start java main method in the server.sh file as below:
$JAVA_HOME/bin/java -jar /home/vcap/app/lib/test.jar

But when I start this application using the following commands:
cf push -t 180 -p ./ --no-start -c "export PATH=/home/vcap/app/.java-buildpack/open_jdk_jre/bin:$PATH; export JAVA_HOME=$PWD/.java-buildpack/open_jdk_jre; export APP_DIR=/home/vcap/app;./bin/server.sh start”
cf enable-diego test
cf set-health-check test none
cf start test

There is the following error:
2015-12-28T22:21:44.49+0800 [CELL/0] OUT Creating container
2015-12-28T22:21:45.35+0800 [CELL/0] OUT Successfully created container
2015-12-28T22:21:46.80+0800 [APP/0] OUT Starting Test Data Application...
2015-12-28T22:21:46.81+0800 [APP/0] OUT Started
2015-12-28T22:21:46.81+0800 [APP/0] OUT Exit status 0
2015-12-28T22:21:46.82+0800 [CELL/0] OUT Exit status 0
2015-12-28T22:21:46.83+0800 [API/0] OUT App instance exited with guid 20f7a19e-8d4b-4ad6-8342-ed886b0be2df payload: {"instance"=>"f132bfe8-fb3e-46e8-5ed5-19ba88cfc887", "index"=>0, "reason"=>"CRASHED", "exit_description"=>"2 error(s) occurred:\n\n* Codependent step exited\n* cancelled", "crash_count"=>3, "crash_timestamp"=>1451312506827459119, "version"=>"bd4b7181-fefb-451f-a072-15ea42ecabfc"}

But if I add the following statements at the end of server.sh file, application can be started without error:
while true
do
sleep 1d
done


Re: Dynamic draining

Matthew Sykes <matthew.sykes@...>
 

This is probably a question for bosh-dev.

...better known as cf-bosh now. :) (whoops)

On Mon, Dec 28, 2015 at 5:30 AM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

It looks like a couple of months back a note was added[1] to the bosh
drain scripts documentation about dynamic draining eventually going the way
of the dodo. Since we use this mechanism a lot to properly control rolling
updates of stateful components, may I ask what's the rationale for this? Is
there an intended replacement for the case in which we can't predict how
long the shutdown procedure is going to take?

Carlo Alberto

---
[1]
https://github.com/cloudfoundry/docs-bosh/commit/0de0f6748717150a123be9aa1b0cacccc25ee8c8#diff-c32ca3c02712812cc2fe8a865ab4b2ccR41


--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: Dynamic draining

Matthew Sykes <matthew.sykes@...>
 

This is probably a question for bosh-dev.

On Mon, Dec 28, 2015 at 5:30 AM, Carlo Alberto Ferraris <
carlo.ferraris(a)rakuten.com> wrote:

It looks like a couple of months back a note was added[1] to the bosh
drain scripts documentation about dynamic draining eventually going the way
of the dodo. Since we use this mechanism a lot to properly control rolling
updates of stateful components, may I ask what's the rationale for this? Is
there an intended replacement for the case in which we can't predict how
long the shutdown procedure is going to take?

Carlo Alberto

---
[1]
https://github.com/cloudfoundry/docs-bosh/commit/0de0f6748717150a123be9aa1b0cacccc25ee8c8#diff-c32ca3c02712812cc2fe8a865ab4b2ccR41


--
Matthew Sykes
matthew.sykes(a)gmail.com


Re: URL of a Service Instance

Rahul Gupta
 

Hi Dieu,

I figured that out and did the following:
1. Created an instance of caching server. As soon as the instance gets created, I extract the hostname and InetAddress of this instance and stores in credentials upon bind request. For example, the host and InetAddress returned is 10.254.0.58.
2. When an app is bound to the service, the credentials do show up in VCAP_SERVICES.
3. I then use the IP address returned in credentials on bind response, in the application to initiate a connection with the caching server. At this point, the app refuses to find any server running at that IP.

So 2 questions:
1. The IP address returned is a private IP. Can an application running on Cloud Foundry connect with a service instance through private IP address? If yes, then do I need to do something special to enable this communication through private IP?
2. How and where do I see the logs of caching server which was created by the broker in createServiceInstance?

Thanks,
Rahul


Re: Communication between Application Instances

Casey West
 

Stevo,

Unfortunately recording for CF Summits Europe and Asia were not done, so no
talk recordings will be made available. :-(

— Casey

On Mon, Dec 28, 2015 at 5:21 AM Stevo Slavić <sslavic(a)gmail.com> wrote:

Found out Context Path Routing was covered on recent Cloud Foundry Summit
Europe, in "Better Microservice Applications Using New Cloud Foundry
Features" session (see
http://berlin2015.cfsummit.com/sites/berlin2015.cfsummit.com/files//pages/files/summit-berlin.pdf
for slides)

Cannot find recordings yet. Hopefully they will get published as well.

On Mon, Dec 28, 2015 at 10:09 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Thanks for heads up! Will give the plugin a try.

On Mon, Dec 28, 2015 at 10:02 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

The Context Path Routing work has been completed on the cloud controller
API side and work to add support for it in the cf cli I believe is nearly
complete.
Until then, you could use this context path route plugin [1]

It's not generally recommended, but if you're running your own CF and
you trust all the apps running there, you could relax your app security
group rules and allow inter-host communication on the DEA with the manifest
configuration that Stevo linked above, in order to allow apps to connect
directly with each other without having to go back out through the router.

[1] https://github.com/zrob/context-route-plugin

On Mon, Dec 28, 2015 at 12:36 AM, Stevo Slavić <sslavic(a)gmail.com>
wrote:

Hello Abhik,

I also have similar need, would like to allow different CF apps to talk
to each other directly (not through CF router service discovery is solved
problem grown ups can handle, potentially not even over HTTP since too much
overhead, no disk persistence needed as app can recreate state).

I was suggested on Cloud Foundry Slack group - use Bosh. Although I use
Bosh already for disk persistent services, IMO Bosh is not appropriate for
this particular use case (not even for disk persistent services, it's too
limited).

There are some proposals to improve CF platform like:
- Proposal: container networking for applications
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/3E7QRIFLC32QK3Q7LMR7FDZPBYLM2BXV/>
- Context Path Routing
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/WDGXFMWRWXG26ZDOGBDPFAN6MQAH4RKH/>

IMO features in those proposals would be very handy to support
deploying stateful apps to CF which can talk with each other, but they are
not there yet.

So there's no fine grained declarative control over routing or
security. I haven't tried it yet, but AFAIK one can only, on the entire CF
installation, allow apps deployed on the same DEA to talk to each other by
configuring
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L36

Kind regards,
Stevo Slavic.

On Mon, Dec 28, 2015 at 5:55 AM, Gupta, Abhik <abhik.gupta(a)sap.com>
wrote:

Hi,

I am curious to know if there’s any guideline or recommendation for
communication between two instances of the same application deployed on
Cloud Foundry. Ideally, there would be no need to have a channel between
the app instances, considering that the application itself should be
stateless.

However, there do arise a few special cases where it becomes necessary
to have communication between two or more instances of the application. Can
you point me to some ways to achieve this?



Best Regards,

Abhik


Re: CF CLI v6.14.1 Released Today

Marco Voelz
 

Nice, thanks Dies!

$ brew tap cloudfoundry/tap
At another occasion I was already advocating for a separation of homebrew taps for pivotal products vs. open-source CF things.

Have you already integrated the update of the tap into your concourse build so I can steal it for other projects? :D
E.g. bosh-init has a pretty outdated version on homebrew, as the update part is not automated in the build process.

Warm regards
Marco


Dynamic draining

Carlo Alberto Ferraris
 

It looks like a couple of months back a note was added[1] to the bosh drain scripts documentation about dynamic draining eventually going the way of the dodo. Since we use this mechanism a lot to properly control rolling updates of stateful components, may I ask what's the rationale for this? Is there an intended replacement for the case in which we can't predict how long the shutdown procedure is going to take?

Carlo Alberto

---
[1] https://github.com/cloudfoundry/docs-bosh/commit/0de0f6748717150a123be9aa1b0cacccc25ee8c8#diff-c32ca3c02712812cc2fe8a865ab4b2ccR41


Re: Communication between Application Instances

Stevo Slavić <sslavic at gmail.com...>
 

Found out Context Path Routing was covered on recent Cloud Foundry Summit
Europe, in "Better Microservice Applications Using New Cloud Foundry
Features" session (see
http://berlin2015.cfsummit.com/sites/berlin2015.cfsummit.com/files//pages/files/summit-berlin.pdf
for slides)

Cannot find recordings yet. Hopefully they will get published as well.

On Mon, Dec 28, 2015 at 10:09 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Thanks for heads up! Will give the plugin a try.

On Mon, Dec 28, 2015 at 10:02 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

The Context Path Routing work has been completed on the cloud controller
API side and work to add support for it in the cf cli I believe is nearly
complete.
Until then, you could use this context path route plugin [1]

It's not generally recommended, but if you're running your own CF and you
trust all the apps running there, you could relax your app security group
rules and allow inter-host communication on the DEA with the manifest
configuration that Stevo linked above, in order to allow apps to connect
directly with each other without having to go back out through the router.

[1] https://github.com/zrob/context-route-plugin

On Mon, Dec 28, 2015 at 12:36 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Hello Abhik,

I also have similar need, would like to allow different CF apps to talk
to each other directly (not through CF router service discovery is solved
problem grown ups can handle, potentially not even over HTTP since too much
overhead, no disk persistence needed as app can recreate state).

I was suggested on Cloud Foundry Slack group - use Bosh. Although I use
Bosh already for disk persistent services, IMO Bosh is not appropriate for
this particular use case (not even for disk persistent services, it's too
limited).

There are some proposals to improve CF platform like:
- Proposal: container networking for applications
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/3E7QRIFLC32QK3Q7LMR7FDZPBYLM2BXV/>
- Context Path Routing
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/WDGXFMWRWXG26ZDOGBDPFAN6MQAH4RKH/>

IMO features in those proposals would be very handy to support deploying
stateful apps to CF which can talk with each other, but they are not there
yet.

So there's no fine grained declarative control over routing or security.
I haven't tried it yet, but AFAIK one can only, on the entire CF
installation, allow apps deployed on the same DEA to talk to each other by
configuring
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L36

Kind regards,
Stevo Slavic.

On Mon, Dec 28, 2015 at 5:55 AM, Gupta, Abhik <abhik.gupta(a)sap.com>
wrote:

Hi,

I am curious to know if there’s any guideline or recommendation for
communication between two instances of the same application deployed on
Cloud Foundry. Ideally, there would be no need to have a channel between
the app instances, considering that the application itself should be
stateless.

However, there do arise a few special cases where it becomes necessary
to have communication between two or more instances of the application. Can
you point me to some ways to achieve this?



Best Regards,

Abhik


Re: Communication between Application Instances

Stevo Slavić <sslavic at gmail.com...>
 

Thanks for heads up! Will give the plugin a try.

On Mon, Dec 28, 2015 at 10:02 AM, Dieu Cao <dcao(a)pivotal.io> wrote:

The Context Path Routing work has been completed on the cloud controller
API side and work to add support for it in the cf cli I believe is nearly
complete.
Until then, you could use this context path route plugin [1]

It's not generally recommended, but if you're running your own CF and you
trust all the apps running there, you could relax your app security group
rules and allow inter-host communication on the DEA with the manifest
configuration that Stevo linked above, in order to allow apps to connect
directly with each other without having to go back out through the router.

[1] https://github.com/zrob/context-route-plugin

On Mon, Dec 28, 2015 at 12:36 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Hello Abhik,

I also have similar need, would like to allow different CF apps to talk
to each other directly (not through CF router service discovery is solved
problem grown ups can handle, potentially not even over HTTP since too much
overhead, no disk persistence needed as app can recreate state).

I was suggested on Cloud Foundry Slack group - use Bosh. Although I use
Bosh already for disk persistent services, IMO Bosh is not appropriate for
this particular use case (not even for disk persistent services, it's too
limited).

There are some proposals to improve CF platform like:
- Proposal: container networking for applications
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/3E7QRIFLC32QK3Q7LMR7FDZPBYLM2BXV/>
- Context Path Routing
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/WDGXFMWRWXG26ZDOGBDPFAN6MQAH4RKH/>

IMO features in those proposals would be very handy to support deploying
stateful apps to CF which can talk with each other, but they are not there
yet.

So there's no fine grained declarative control over routing or security.
I haven't tried it yet, but AFAIK one can only, on the entire CF
installation, allow apps deployed on the same DEA to talk to each other by
configuring
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L36

Kind regards,
Stevo Slavic.

On Mon, Dec 28, 2015 at 5:55 AM, Gupta, Abhik <abhik.gupta(a)sap.com>
wrote:

Hi,

I am curious to know if there’s any guideline or recommendation for
communication between two instances of the same application deployed on
Cloud Foundry. Ideally, there would be no need to have a channel between
the app instances, considering that the application itself should be
stateless.

However, there do arise a few special cases where it becomes necessary
to have communication between two or more instances of the application. Can
you point me to some ways to achieve this?



Best Regards,

Abhik


Re: Communication between Application Instances

Dieu Cao <dcao@...>
 

The Context Path Routing work has been completed on the cloud controller
API side and work to add support for it in the cf cli I believe is nearly
complete.
Until then, you could use this context path route plugin [1]

It's not generally recommended, but if you're running your own CF and you
trust all the apps running there, you could relax your app security group
rules and allow inter-host communication on the DEA with the manifest
configuration that Stevo linked above, in order to allow apps to connect
directly with each other without having to go back out through the router.

[1] https://github.com/zrob/context-route-plugin

On Mon, Dec 28, 2015 at 12:36 AM, Stevo Slavić <sslavic(a)gmail.com> wrote:

Hello Abhik,

I also have similar need, would like to allow different CF apps to talk to
each other directly (not through CF router service discovery is solved
problem grown ups can handle, potentially not even over HTTP since too much
overhead, no disk persistence needed as app can recreate state).

I was suggested on Cloud Foundry Slack group - use Bosh. Although I use
Bosh already for disk persistent services, IMO Bosh is not appropriate for
this particular use case (not even for disk persistent services, it's too
limited).

There are some proposals to improve CF platform like:
- Proposal: container networking for applications
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/3E7QRIFLC32QK3Q7LMR7FDZPBYLM2BXV/>
- Context Path Routing
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/WDGXFMWRWXG26ZDOGBDPFAN6MQAH4RKH/>

IMO features in those proposals would be very handy to support deploying
stateful apps to CF which can talk with each other, but they are not there
yet.

So there's no fine grained declarative control over routing or security. I
haven't tried it yet, but AFAIK one can only, on the entire CF
installation, allow apps deployed on the same DEA to talk to each other by
configuring
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L36

Kind regards,
Stevo Slavic.

On Mon, Dec 28, 2015 at 5:55 AM, Gupta, Abhik <abhik.gupta(a)sap.com> wrote:

Hi,

I am curious to know if there’s any guideline or recommendation for
communication between two instances of the same application deployed on
Cloud Foundry. Ideally, there would be no need to have a channel between
the app instances, considering that the application itself should be
stateless.

However, there do arise a few special cases where it becomes necessary to
have communication between two or more instances of the application. Can
you point me to some ways to achieve this?



Best Regards,

Abhik


Re: How to save in file bits of an App

Dieu Cao <dcao@...>
 

The curl examples in the existing api docs aren't great. We hope to
improve that in future.

You can do this with cf curl fairly easily with the --output flag.

For example:

$ cf curl /v2/apps/ef01a7da-9569-437b-bbf4-3f2dd01635ef/download --output
myapp.zip

-Dieu
CF CAPI PM

On Thu, Dec 24, 2015 at 11:28 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Good afternoon and Merry Christmas,

I am trying to save in disk bits from an App but I have some problems
using this method:
http://apidocs.cloudfoundry.org/226/apps/downloads_the_bits_for_an_app.html

Does exist some details to store in the right way?

Many thanks in advance.

Juan Antonio


Re: Is it possible to upload a droplet?

Dieu Cao <dcao@...>
 

Hi,

It's not currently possible to directly upload a droplet once you have
downloaded a droplet.
You could hack your way to this by downloading a droplet and uploading it
with the binary buildpack if you specify the start command and also account
for recreating sym links that may be missed on upload.

This is something that we may take a look at supporting in the future, but
is not currently prioritized.

-Dieu
CF CAPI PM


On Thu, Dec 24, 2015 at 11:29 AM, Juan Antonio Breña Moral <
bren(a)juanantonio.info> wrote:

Hi,

I am downloading a droplet and I would like to know if it is possible to
upload a droplet once you have downloaded in a host:

http://apidocs.cloudfoundry.org/226/apps/downloads_the_staged_droplet_for_an_app.html

in order to upload to another host and later restage.

Many thanks in advance.

Merry Christmas

Juan Antonio


Re: URL of a Service Instance

Dieu Cao <dcao@...>
 

Hi Rahul,

As mentioned above and described in the docs, it is up to you to implement
the code in your service broker to actually provision and store connection
information when there is a request to provision an instance of whatever
service you are providing.

It is up to you to implement the code in your service broker to return that
connection information, (ip, port, password, etc) to cloud controller when
your service broker receives a request to bind an app to a service
instance. In your response, you must include `credentials` as a hash, that
includes the connection information.

It is only then, if you have implemented code that returns connection
information in response to the bind request, will cloud controller make
that credentials hash that includes the connection information available as
part of the VCAP_SERVICES environment variable.

-Dieu
CF CAPI PM

On Sat, Dec 26, 2015 at 6:09 PM, Rahul Gupta <wildnez(a)gmail.com> wrote:

Hi Scott,

My service broker creates an instance of caching server, similar to what
mongodb does. An application that is going to use this caching server, will
be using its client API to connect. So when the application binds with the
service, the caching client in the app requires IP address or host name of
the caching server that was created by the broker.

From the example what Marco provided earlier:
Look at this URI provided by the mysql service broker: mysql://
25vHYlC5qhmHzmL6:8bSS58gjtzgznbke@
10.0.163.11:3306/cf_ccfd8402_83b2_4ab2_a803_4b8ad9551bc8?reconnect=true "

Its this IP address 10.0.163.11 and port 3306, what I am referring to.

My assumption was that once an application binds with a service, Cloud
Foundry itself would provide configuration details to the application to
make the connection between app and service instance possible. I looked at
VCAP_SERVICES but they do not contain any such information by default. So,
I assumed that such kind of connection details are to be provided by the
user only; therefore asking about the IP address of service instance.

By the way, are there any other environment variable that I missed to
check?

Thanks,
Rahul


Re: Communication between Application Instances

Stevo Slavić <sslavic at gmail.com...>
 

Hello Abhik,

I also have similar need, would like to allow different CF apps to talk to
each other directly (not through CF router service discovery is solved
problem grown ups can handle, potentially not even over HTTP since too much
overhead, no disk persistence needed as app can recreate state).

I was suggested on Cloud Foundry Slack group - use Bosh. Although I use
Bosh already for disk persistent services, IMO Bosh is not appropriate for
this particular use case (not even for disk persistent services, it's too
limited).

There are some proposals to improve CF platform like:
- Proposal: container networking for applications
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/3E7QRIFLC32QK3Q7LMR7FDZPBYLM2BXV/>
- Context Path Routing
<https://lists.cloudfoundry.org/archives/list/cf-dev(a)lists.cloudfoundry.org/message/WDGXFMWRWXG26ZDOGBDPFAN6MQAH4RKH/>

IMO features in those proposals would be very handy to support deploying
stateful apps to CF which can talk with each other, but they are not there
yet.

So there's no fine grained declarative control over routing or security. I
haven't tried it yet, but AFAIK one can only, on the entire CF
installation, allow apps deployed on the same DEA to talk to each other by
configuring
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L36

Kind regards,
Stevo Slavic.

On Mon, Dec 28, 2015 at 5:55 AM, Gupta, Abhik <abhik.gupta(a)sap.com> wrote:

Hi,

I am curious to know if there’s any guideline or recommendation for
communication between two instances of the same application deployed on
Cloud Foundry. Ideally, there would be no need to have a channel between
the app instances, considering that the application itself should be
stateless.

However, there do arise a few special cases where it becomes necessary to
have communication between two or more instances of the application. Can
you point me to some ways to achieve this?



Best Regards,

Abhik


Communication between Application Instances

Gupta, Abhik
 

Hi,
I am curious to know if there's any guideline or recommendation for communication between two instances of the same application deployed on Cloud Foundry. Ideally, there would be no need to have a channel between the app instances, considering that the application itself should be stateless.
However, there do arise a few special cases where it becomes necessary to have communication between two or more instances of the application. Can you point me to some ways to achieve this?

Best Regards,
Abhik


Re: URL of a Service Instance

Rahul Gupta
 

Hi Scott,

My service broker creates an instance of caching server, similar to what mongodb does. An application that is going to use this caching server, will be using its client API to connect. So when the application binds with the service, the caching client in the app requires IP address or host name of the caching server that was created by the broker.

From the example what Marco provided earlier:
Look at this URI provided by the mysql service broker: mysql:// 25vHYlC5qhmHzmL6:8bSS58gjtzgznbke@10.0.163.11:3306/cf_ccfd8402_83b2_4ab2_a803_4b8ad9551bc8?reconnect=true "

Its this IP address 10.0.163.11 and port 3306, what I am referring to.

My assumption was that once an application binds with a service, Cloud Foundry itself would provide configuration details to the application to make the connection between app and service instance possible. I looked at VCAP_SERVICES but they do not contain any such information by default. So, I assumed that such kind of connection details are to be provided by the user only; therefore asking about the IP address of service instance.

By the way, are there any other environment variable that I missed to check?

Thanks,
Rahul


Re: URL of a Service Instance

Scott Frederick <scottyfred@...>
 

Rahul,

It is a bit unclear what you mean by “the IP address of service instance”,
and that is making it difficult to answer your questions. Can you explain
more about the type of resource your broker is creating, and what the
connection details and credentials for provisioned service instances should
look like?

Service brokers typically provision resources (e.g. a database instance)
and are in complete control of where the resources are created. Brokers
should have their own means of persisting the details of a service instance
provisioning request in order to build the credentials for a binding
request later. The spring-boot-cf-service-broker project provides the means
to return the connection details and credentials for the provisioned
resources, but it does not help with determining where any resources get
created or with persisting the results of a provision request for later use
in a binding request. As such, there is no API in Spring Boot or
spring-boot-cf-service-broker that can provide you the IP address of the
service instance that the broker provisions. APIs are only provided to
return this data after your broker implementation code has created a
service instance.

Scott

On Fri, Dec 25, 2015 at 11:15 PM, Rahul Gupta <wildnez(a)gmail.com> wrote:

Hi Marco,

Thanks for yet another detailed explanation, it really helps. Its the IP
address in example URI that I was looking for and I still need some help on
that part. Please correct me if I understand your explanation wrong - you
mentioned that the IP address of service instance comes from BOSH manifest,
so did you mean the IP address of all service instances remains constant
for all service instances? Or does the BOSH director creates a new IP
address (picked from a range configured in bosh manifest may be) for every
service instance that gets created?

Also, is there an API in Spring Boot framework that can provide me the IP
address of the service instance that the framework itself is going to
create? I am referring to the implementation of
org.cloudfoundry.community.servicebroker.service.ServiceInstanceService

In this interface, I am required to provide the implementation of methods
like:
createServiceInstance
getServiceInstance

and a couple of other methods. And for binding, the implementation of
org.cloudfoundry.community.servicebroker.service.ServiceInstanceBindingService,
requires me to implement createServiceInstanceBinding and
deleteServiceInstanceBinding. In createServiceInstanceBinding, I can return
the IP address of the service instance I am creating on this request as
credential to the application. And this is where I need to know what is
going to be the IP address of this service instance.

Now you have said that the IP addresses are picked from BOSH manifest and
use ERB to create config data - could you please elaborate on this? Are the
IPs created at the run time when a service instance is created? If yes then
how do I obtain the IP and inject into Spring Boot framework as I asked
earlier. If no then which configuration from BOSH or CF manifest can help
me?

I am new to BOSH and Ruby, so please pardon me for asking so many basic
questions.

fyi - I used bosh-init to deploy BOSH director.

Many thanks,
Rahul


Re: URL of a Service Instance

Rahul Gupta
 

Hi Marco,

Thanks for yet another detailed explanation, it really helps. Its the IP address in example URI that I was looking for and I still need some help on that part. Please correct me if I understand your explanation wrong - you mentioned that the IP address of service instance comes from BOSH manifest, so did you mean the IP address of all service instances remains constant for all service instances? Or does the BOSH director creates a new IP address (picked from a range configured in bosh manifest may be) for every service instance that gets created?

Also, is there an API in Spring Boot framework that can provide me the IP address of the service instance that the framework itself is going to create? I am referring to the implementation of org.cloudfoundry.community.servicebroker.service.ServiceInstanceService

In this interface, I am required to provide the implementation of methods like:
createServiceInstance
getServiceInstance

and a couple of other methods. And for binding, the implementation of org.cloudfoundry.community.servicebroker.service.ServiceInstanceBindingService, requires me to implement createServiceInstanceBinding and deleteServiceInstanceBinding. In createServiceInstanceBinding, I can return the IP address of the service instance I am creating on this request as credential to the application. And this is where I need to know what is going to be the IP address of this service instance.

Now you have said that the IP addresses are picked from BOSH manifest and use ERB to create config data - could you please elaborate on this? Are the IPs created at the run time when a service instance is created? If yes then how do I obtain the IP and inject into Spring Boot framework as I asked earlier. If no then which configuration from BOSH or CF manifest can help me?

I am new to BOSH and Ruby, so please pardon me for asking so many basic questions.

fyi - I used bosh-init to deploy BOSH director.

Many thanks,
Rahul


With authentic technic seo...

Shilpa Arrora <shilpa.seoexpert1@...>
 

Hello Sir/Madam,

Hope you well,

Do you want more targeted visitors/customers on your website, if so; we are
here to help you for your business Growth?

I am affiliated with an SEO company based in India that has helped over 300+
businesses rank on 1st Page Ranking on (GOOGLE) for even the most
competitive Industries over the globe.

Increase more visitors' traffic--------> more clients -----------> more
business ----------> more money

Please ask us for more information and Quote for latest SEO Plan.

Warm Regards,

Shilpa Arrora

Online SEO Consultant
IT-Department:-Though this is not an automated email, we are sending these
emails to all those people whom we find eligible of using our services. To
unsubscribe from future mails (i.e., to ensure that we do not contact you
again for this matter), Please send us a mail back.

6161 - 6180 of 9398