Date   

Re: aligning cf push health-check default value

Nicholas Calugar
 

Hi Dies,

I considered this a bit more after we chatted yesterday and I don't think
we should try to create parity between DEAs and Diego in this case. My
personal opinion is that behavior should be explicit and these two flags
provide a more correct experience with the Diego backend.


Thanks,

Nick

On Mon, Apr 25, 2016 at 6:09 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

Hi CLI users,



With apps deployed to DEAs, a health check is performed at application
start-up targeting the app’s port, unless you specified `--no-route`, in
which case the process is monitored.

With Diego, the health check is performed continuously and the type of
check was exposed through an option to the `cf push` command.

This option defaults to `port`, which isn't always appropriate for apps
pushed without a route, such as worker apps.



We propose fixing the `--health-check-type` option’s default value to
align with the behaviour seen for DEAs, i.e. to use “none” if option
`--no-route` is used:



--health-check-type, -u Application health check type (Default:
'none' if '--no-route' is set, otherwise 'port')`

Would anyone object to such change?



Cheers,

Dies Koper
Cloud Foundry CLI PM





CF CLI v6.17.1 Released Today

Koper, Dies <diesk@...>
 

The CF CLI team just cut 6.17.1. Binaries and link to release notes are available at:

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

Note that we've been working with the Docs team to publish instructions on how to use the CLI securely with a CF deployment that uses a self-signed certificate (or a certificate not signed by a CA certificate available on the client machine): http://docs.cloudfoundry.org/cf-cli/self-signed.html

HTTPS for CF-Community plugin repo

The "CF-Community" plugin repo that is registered with the CLI by default now uses HTTPS.
Unless your local ~/.cf/config.json is removed, the "CF-Community" repo's URL displayed in cf list-plugin-repos will continue to start with "http://", but actual calls to it will be made securely. To update the displayed URL, either delete ~/.cf/config.json and re-login, or update it manually (cf remove-plugin-repo CF-Community && cf add-plugin-repo CF-Community https://plugins.cloudfoundry.org).

Windows Installer

The 64 bit and 32 bit Windows installers are now digitally signed with a Cloud Foundry Foundation certificate, so no more warnings popping up that it is not trusted because it has no publisher.

Windows Coloring

The CLI can now display messages in colors on Windows, as it has on Linux and Mac OS. Use cf config --color true to enable it. Note that it has a side-effect of adding ansi codes in the trace log. That will be addressed in a next release.

Linux 64 bit Static Linking

The Linux 64 bit release is now statically linked (the 32 bit one was already), allowing it to run on alternative distributions such as Alpine.

NOAA client library

The CLI now uses the NOAA client library (https://github.com/cloudfoundry/noaa) instead of Loggregator Consumer (https://github.com/cloudfoundry/loggregator_consumer) to obtain application log messages and metrics. This should not affect CLI users other than that it fixes a regression in cf CLI 6.17.0 with pushing multiple applications defined in an app manifest.

Error Handling for CF_HOME

The CLI will no longer try to create a directory for its local config.json file if the path that environment variable CF_HOME points to does not exist; instead it will return a meaningful error message.

Updated Plugins:

* antifreeze v0.2.1: https://github.com/odlp/antifreeze

Enjoy!

Regards,
Dies Koper
Cloud Foundry CLI PM


Re: HTTP request status text is changed

Ben Hale <bhale@...>
 

The Java Buildpack creates a very complex command to start applications (since it needs to manage the JVM’s memory space within the container’s memory space). Therefore, it detects standard artifact types listed in the documentation[1] and builds the command based on that. For self-executable JARs, detection is based on the Java standard `Main-Class` key in the `META-INF/MANFIEST.MF`[2]. You’ll need to remember that when you push the WAR or JAR to Cloud Foundry, it is expanded and presented to the buildpack in an exploded form. We read files off the filesystem and execute the application in that layout. So, for example, there is no `testId.war` on the filesystem in the container, only the contents of the WAR that was pushed.


-Ben Hale
Cloud Foundry Java Experience



[1]: https://github.com/cloudfoundry/java-buildpack#additional-documentation
[2]: https://github.com/cloudfoundry/java-buildpack/blob/master/docs/container-java_main.md

On May 3, 2016, at 11:25, Stanley Shen <meteorping(a)gmail.com> wrote:

Can you have a try with the attached jettty.zip.txt in previous reply to see if you reproduce it?
It's used to simulate my APP, you can just download it and change to jetty.zip and unzip it.
There is a manifest file along with a war file and jetty runner.
You can push it to a bosh lite VM and you should see the issue.

In this sample, actually there is nothing special configured for jetty.
we just run it like "java -jar jetty-runner.jar --port $PORT testId.war" in the container.

My APP is quite large and has many dependencies, which make it not easy to post somewhere.


Re: HTTP request status text is changed

Stanley Shen <meteorping@...>
 

Can you have a try with the attached jettty.zip.txt in previous reply to see if you reproduce it?
It's used to simulate my APP, you can just download it and change to jetty.zip and unzip it.
There is a manifest file along with a war file and jetty runner.
You can push it to a bosh lite VM and you should see the issue.

In this sample, actually there is nothing special configured for jetty.
we just run it like "java -jar jetty-runner.jar --port $PORT testId.war" in the container.

My APP is quite large and has many dependencies, which make it not easy to post somewhere.


Re: HTTP request status text is changed

CF Runtime
 

Ok thanks for clarifying. It sounds like your java app is a WAR, not a JAR, correct? Or, perhaps it's a jar, but it's a non-executable jar - it cannot be run with `java -jar my-web-app.jar`

If you create a jar that is executable as above, Cloud Foundry will just run it - so you'll get all of your custom jetty configuration. If instead, you require some other command to run this, CF will not be able to infer this, and your servlets will be run inside of a tomcat instance created by the buildpack.

If you cannot make your app an executable jar, you will have to rely on the buildpack behavior, which is non-configurable, unless you fork it.

Can you post a sanitized version of your actual app (or DM it to someone from the #release-integration channel in cloudfoundry.slack.com). Without your custom configuration we cannot really proceed.

Thanks,
Rob Dimsdale & Alvaro Perez-Shirley
CF Release Integration
Pivotal


NOAA Library Update

Warren Fernandes
 

Hello cf-dev,

Loggregator has been working on some improvements to the NOAA library.

The recommended way to create a NOAA consumer is now consumer.New(...)
under the consumer package instead of the legacy method of
noaa.NewConsumer(...). consumer.Consumer has some minor changes from
noaa.Consumer:

- Methods that accepted channels now return read-only channels, which the
consumer will close once it is done with them

- There is no Closed method.

- The new consumer can be used for multiple websocket calls, and all
previous connections (and the corresponding returned channels) will be
closed when Close is called.


The consumer within the noaa package is now deprecated and will be removed
in the near future.

We also added friendly reminders and warnings in the README
<https://github.com/cloudfoundry/noaa#deprecation> and stderr
<https://github.com/cloudfoundry/noaa/blob/master/consumer.go#L59> output.

Thanks.
Loggregator Team


Updating the default version of Ruby to 2.3.x

John Shahid
 

Hi all,

We'd like to let you know that in the next week we'll be scheduling work to
update the default version of Ruby in the Ruby Buildpack from 2.2.x to
2.3.x. This change only affects application that don't specify the version
of Ruby in the Gemfile.

Please let us know if this is an undesired change. Also, please keep in
mind that you can always force the buildpack to use a specific version of
ruby by adding the following line to your `Gemfile`:

```
ruby "2.2.4"
```

Cheers,

JS


Re: unable to push buildback and even CF-app command

Daniel Mikusa
 

On Tue, May 3, 2016 at 3:23 AM, Bala Murugan <balamurugan151187(a)gmail.com>
wrote:

Hi,

We are trying to push an buildpack using cf creat-buildpack command and
below are the CF_TRACE logs

REQUEST: [2016-05-03T06:20:46Z]
PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits HTTP/1.1
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data;
boundary=be0b00f857ab0afc2960021bde74f00694661d064034c3901d96b022952f
User-Agent: go-cli 6.16.1+924508c / linux


[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading

RESPONSE: [2016-05-03T06:21:46Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

Its getting failed. Can you please suggest us on how to trouble shoot it..
The time stamp on the request and response are exactly 60 seconds apart.
Do you have any timeouts that are set to 60 seconds? Perhaps on your load
balancer?

Dan


The Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals and Forecasts

SNS Research <e.hall@...>
 

Hello,

Hope you are doing well.

I wanted to bring to your attention the latest SNS Research report in which you might be interested, " The Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals and Forecasts."

I believe this report will be highly applicable for you. If you would like to see the report sample or have any questions, please let me know.

Report Information:

Release Date: May 2016
Number of Pages: 219

Report Overview:

While wearable technology has been utilized in vertical sectors such as the military and healthcare industries for many years, ongoing advances have triggered a major resurgence of the concept, particularly among the consumer community. Key enabling technologies including low cost sensors, wireless connectivity, active materials and energy have converged to make wearable technology mainstream.

With the continued miniaturization of enabling technologies, wearable devices have hit the mass market in a diverse variety of form factors, ranging from glasses to even jewelry.

Driven by the ability to interconnect with key modern trends of healthcare, fitness, messaging and socialization, the wearable technology ecosystem is attracting significant levels of interest. Companies as varied as smartphone OEMs, mobile operators, health insurers and retailers are circling the ecosystem alongside tiny startups, all vying for a stake.

SNS Research estimates that wearable device shipments will grow at a CAGR of 29% between 2016 and 2020. By 2020, wearable devices will represent a market worth $40 Billion with over 240 Million annual unit shipments.

The "Wearable Technology Ecosystem: 2016 - 2030 - Opportunities, Challenges, Strategies, Industry Verticals & Forecasts" report presents an in-depth assessment of the wearable technology ecosystem including key market drivers, challenges, investment potential, consumer & vertical market opportunities, use cases, future roadmap, value chain, case studies, vendor market share and strategies. The report also presents forecasts for wearable device shipments and revenue from 2016 through to 2030. The forecasts are further segmented for 7 device form factor submarkets, 7 vertical markets, 6 regions and 73 countries.

The report comes with an associated Excel datasheet suite covering quantitative data from all numeric forecasts presented in the report.


Key Findings:

The report has the following key findings:
SNS Research estimates that wearable device shipments will grow at a CAGR of 29% between 2016 and 2020. By 2020, wearable devices will represent a market worth $40 Billion with over 240 Million annual unit shipments.
Leading smartphone OEMs, Apple and Samsung, are replicating their success in the OS powered smart watch arena with a combined market share of nearly 75%.
As wearable device OEMs seek to minimize dependence on hardware sales, new business models are beginning to emerge, particularly in the enterprise space. For example, specialist vendors such as Catapult are offering subscription based services to sports teams, which combine wearable sensors, cloud-based software and analytics.
SNS Research estimates that wearable devices will help mobile operators drive over $13 Billion in service revenue by the end of 2020, following a CAGR of nearly 32% between 2016 and 2020.
The market is ripe for acquisitions of pure-play wearable technology startups, as competition heats up between consumer and vertical centric OEMs.

Topics Covered:

The report covers the following topics:
Wearable technology ecosystem
Market drivers and barriers
Enabling technologies and operating systems for wearable devices
Standardization and regulation landscape
Wearable technology industry roadmap and value chain
Assessment of vertical market opportunities and use cases for consumer, healthcare, professional sports, retail & hospitality, military, public safety and 8 other verticals
Case studies of wearable technology deployments
Company profiles and strategies of over 440 wearable technology ecosystem players
Wearable device vendor market share
Prospects of smartphone OEMs and wireless chipset suppliers in the wearable technology ecosystem
Impact of 5G, NB-IoT and LTE Direct on wearable technology
Strategic recommendations for enabling technology providers, wearable device OEMs, vertical market players, application developers and mobile operators
Market analysis and forecasts from 2016 till 2030

Forecast Segmentation:
Market forecasts are provided for each of the following submarkets and their categories:
Vertical Submarkets
Consumer
Healthcare
Professional Sports
Retail & Hospitality
Military
Public Safety
Others
Form Factor Submarkets
Smart Bands
Smart Watches
Smart Glasses
Smart Clothing
Smart Jewelry
Heads-up Displays
Others
Regional Markets
Asia Pacific
Eastern Europe
Latin & Central America
Middle East & Africa
North America
Western Europe
Country Markets
73 Country level markets: Algeria, Argentina, Australia, Austria, Bangladesh, Belarus, Belgium, Bolivia, Bosnia & Herzegovina, Brazil, Bulgaria, Canada, Chile, China, Colombia, Croatia, Czech Republic, Denmark, Ecuador, Egypt, Finland, France, Germany, Greece, Hong Kong, Hungary, India, Indonesia, Ireland, Israel, Italy, Japan, Kenya, Luxembourg, Malaysia, Mexico, Morocco, Netherlands, New Zealand, Nigeria, Norway, Pakistan, Paraguay, Peru, Philippines, Poland, Portugal, Qatar, Romania, Russia, Saudi Arabia, Serbia, Singapore, Slovakia, South Africa, South Korea, Spain, Sudan, Sweden, Switzerland, Taiwan, Tanzania, Thailand, Tunisia, Turkey, UAE, UK, Ukraine, Uruguay, USA, Uzbekistan, Venezuela and Vietnam

Key Questions Answered:

The report provides answers to the following key questions:
How big is the wearable technology ecosystem?
How is the ecosystem evolving by segment and region?
What will the market size be in 2020 and at what rate will it grow?
What trends, challenges and barriers are influencing its growth?
Who are the key wearable device vendors and what are their strategies?
How much are vertical enterprises investing in wearable devices?
What opportunities exist for wireless chipset suppliers in the wearable technology ecosystem?
How can mobile operators capitalize on the growing popularity of smart watches, fitness bands, smart glasses and other wearable devices?
Which countries, regions and verticals will see the highest percentage of wearable device shipments?
Which sports category will see the highest level of wearable technology integration?

Report Pricing:

Single User License: USD 2,500

Company Wide License: USD 3,500


Ordering Process:

Please contact Emily Hall at e.hall(a)snscommunication.com

And provide the following information:
Report Title:
Report License (Single User/Company Wide):
Name:
Email:
Job Title:
Company:

Please contact me if you have any questions, or wish to purchase a copy.

I look forward to hearing from you.

Kind Regards,

Emily Hall

Sales Director
Signals and Systems Research
Email: e.hall(a)snscommunication.com
Address: Reef Tower
Jumeirah Lake Towers
Sheikh Zayed Road
Dubai, UAE

To unsubscribe, please reply to this email with unsubscribe in the subject line.


Re: HTTP request status text is changed

Stanley Shen <meteorping@...>
 

So to be precise, my APP is a jetty based application, it includes jetty
jars and related jetty configuration files.
When this application is deployed on ubuntu (Non-CF) environment, we can
get expect status message we customized.
But when deploying to CF, the customized message is always changed to the
standard status message.
Since all the jetty jars and configuration files are included in our APP
already, so there should no difference in jetty part.

That's why we suspect the problem is in CF related things, but really got
no clue where is it.
We do have some code related to this behavior, and since it's standard
servlet behavior, so I think we should supports it?
http://www.java2s.com/Code/JavaAPI/javax.servlet.http/HttpServletResponsesendErrorintarg0Stringarg1.htm


Attached is one simple jetty based application, when I run it locally I can
get my customized message.

wget http://localhost:8080/hello
--2016-05-03 18:15:22-- http://localhost:8080/hello
Resolving localhost... 127.0.0.1, ::1
Connecting to localhost|127.0.0.1|:8080... connected.
HTTP request sent, awaiting response... 403 my customized 413 error message
2016-05-03 18:15:22 ERROR 403: my customized 413 error message.

When pushing to CF, I still got the standard message.
HTTP request sent, awaiting response... 403 Forbidden
2016-05-03 18:18:46 ERROR 403: Forbidden.

Thanks,
Stanley

On 3 May 2016 at 10:49, Stanley Shen <meteorping(a)gmail.com> wrote:

Thanks for investigation.

Actually my APP is a jetty based application, the APP releases included
all required jetty jar and configuration files, so it should not related to
this tomcat setting?

As tomcat can reproduce my issue easily so I took tomcat for example.


unable to push buildback and even CF-app command

Bala Murugan
 

Hi,

We are trying to push an buildpack using cf creat-buildpack command and below are the CF_TRACE logs

REQUEST: [2016-05-03T06:20:46Z]
PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits HTTP/1.1
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data; boundary=be0b00f857ab0afc2960021bde74f00694661d064034c3901d96b022952f
User-Agent: go-cli 6.16.1+924508c / linux


[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading

RESPONSE: [2016-05-03T06:21:46Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

Its getting failed. Can you please suggest us on how to trouble shoot it..

Thanks,
Bala


unable to push buildback and even CF-app command

Bala Murugan
 

Hi,

We are trying to push an buildpack using cf creat-buildpack command and below are the CF_TRACE logs

REQUEST: [2016-05-03T06:20:46Z]
PUT /v2/buildpacks/9899f3d5-8eab-454e-accb-fcb6d139d69f/bits HTTP/1.1
Accept: application/json
Authorization: [PRIVATE DATA HIDDEN]
Content-Type: multipart/form-data; boundary=be0b00f857ab0afc2960021bde74f00694661d064034c3901d96b022952f
User-Agent: go-cli 6.16.1+924508c / linux


[MULTIPART/FORM-DATA CONTENT HIDDEN]
Done uploading

RESPONSE: [2016-05-03T06:21:46Z]
HTTP/1.1 504 GATEWAY_TIMEOUT
Content-Length: 0
Connection: keep-alive

Its getting failed. Can you please suggest us on how to trouble shoot it..

Thanks,
Bala


Re: HTTP request status text is changed

Stanley Shen <meteorping@...>
 

Thanks for investigation.

Actually my APP is a jetty based application, the APP releases included all required jetty jar and configuration files, so it should not related to this tomcat setting?

As tomcat can reproduce my issue easily so I took tomcat for example.


Re: PHP Buildpack: Now with persistent session support

Etourneau Gwenn
 

Agree ! That's awesome !

Envoyé de mon iPhone

Le 3 mai 2016 à 08:19, Mike Youngstrom <youngm(a)gmail.com> a écrit :

This is awesome! Thanks guys!

Mike

On Mon, May 2, 2016 at 12:29 PM, Danny Rosen <drosen(a)pivotal.io> wrote:
Hi there!

We wanted to let you know of a significant feature addition to the PHP buildpack. Thanks to Daniel Mikusa and the Buildpacks team the PHP Buildpack now has support for persistent sessions in both Redis and Memcached.

Check out the documentation here and give it a spin.


Re: PHP Buildpack: Now with persistent session support

Mike Youngstrom
 

This is awesome! Thanks guys!

Mike

On Mon, May 2, 2016 at 12:29 PM, Danny Rosen <drosen(a)pivotal.io> wrote:

Hi there!

We wanted to let you know of a significant feature addition to the PHP
buildpack. Thanks to Daniel Mikusa and the Buildpacks team the PHP
Buildpack now has support for persistent sessions in both Redis and
Memcached.

Check out the documentation here
<https://github.com/cloudfoundry/php-buildpack/blob/develop/docs/sessions.md>
and give it a spin.


Re: VCAP_APPLICATION in the V3 Cloud Foundry API

Sabha
 

Agree with Dan.

Currently most APM vendors use the VCAP_APPLICATION env variable for
mapping and keeping track of a specific instance using the instance guid,
instance index, app guid fields. Changing it would affect the buildpacks
and extensions.

Sample for AppD APM:
default_node_name: $(ruby -e "require 'json' ; a =
JSON.parse(ENV['VCAP_APPLICATION']);

puts \"#{a['application_name']}:#{a['instance_index']}\"")
Some of these complex expressions might become simpler, as long as the
values still come through with different names.

So, as long as the current set of values continue to exist and either in
flat or easy to grab from ENV, I am okay with that.

thanks,
Sabha

On Mon, May 2, 2016 at 2:19 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I have a few customers that grab that instance index to aid in monitoring
and logging and to self identify in certain situations. Is there an issue
with continuing to expose the instance index?

I don't know anything about v2 vs v3 apis. Would VCAP_APPLICATION
continue to work for apps pushed using the v2 api and only have this new
value if pushed using the v3 api?

Mike

On Mon, May 2, 2016 at 2:49 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick
--
Sabha Parameswaran
Platform Engineering, Cloud Foundry
Pivotal, Inc.
m: +1 (415) 244-5554


Re: VCAP_APPLICATION in the V3 Cloud Foundry API

Mike Youngstrom
 

I have a few customers that grab that instance index to aid in monitoring
and logging and to self identify in certain situations. Is there an issue
with continuing to expose the instance index?

I don't know anything about v2 vs v3 apis. Would VCAP_APPLICATION continue
to work for apps pushed using the v2 api and only have this new value if
pushed using the v3 api?

Mike

On Mon, May 2, 2016 at 2:49 PM, Daniel Mikusa <dmikusa(a)pivotal.io> wrote:

I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Re: VCAP_APPLICATION in the V3 Cloud Foundry API

Daniel Mikusa
 

I know some of the build packs will look at application name and use that
for configuration of some of the APM agents (NewRelic, AppDynamics, etc..).


Ex:
https://github.com/cloudfoundry/java-buildpack/blob/master/config/app_dynamics_agent.yml#L21

The PHP build pack does this too.

As long as that info is exposed somewhere, it would be OK.

Dan

On Mon, May 2, 2016 at 4:34 PM, john mcteague <john.mcteague(a)gmail.com>
wrote:

While I dont use this directly, my first reaction is some libraries such
as Spring Cloud Connectors depend on this to identify that an app is
running in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


Re: VCAP_APPLICATION in the V3 Cloud Foundry API

john mcteague <john.mcteague@...>
 

While I dont use this directly, my first reaction is some libraries such as
Spring Cloud Connectors depend on this to identify that an app is running
in CF, and we rely heavily on Spring Cloud Connectors.

That being said, assuming there are alternative variable that uniquely
identify CF, the library authors could key off that instead.

On Mon, May 2, 2016 at 9:28 PM, Nicholas Calugar <ncalugar(a)pivotal.io>
wrote:

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share?
Are there Cloud Foundry operators / users that would like to get rid of
this all together? Our current plan was to do something like below, but
wanted to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick


VCAP_APPLICATION in the V3 Cloud Foundry API

Nicholas Calugar
 

Hi CF-Dev,

The CAPI team is working hard to get to MVP for V3 of the Cloud Foundry
API. You can follow along by visiting our documentation and tracker:

http://v3-apidocs.cloudfoundry.org/
https://www.pivotaltracker.com/n/projects/966314

We'd like to get some feedback from the community regarding
VCAP_APPLICATION, an environment variable provided to applications running
on Cloud Foundry. In V3, an application contains 1 or more processes that
can be scaled independently, so VCAP_APPLICATION doesn't quite fit.

Do you have any use cases around VCAP_APPLICATION that you could share? Are
there Cloud Foundry operators / users that would like to get rid of this
all together? Our current plan was to do something like below, but wanted
to hear from the community first.

"CF_APPLICATION_PROCESS": {
"space": {
"guid": "682e10a0-6f3a-4a9f-b52c-f508b2bd99c6",
"name": "ncalugar-a1"
},
"application": {
"guid": "<v3-app-guid>",
"name": "nickdora"
"version": "<app-version-guid>"
},
"process": {
"guid": "<v3-proc-guid>",
"type": "web",
"ports": [8080,8081]
},
"route_mappings": [
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com",
"port": 8080
},
{
"guid": "<v3-route-mapping-guid>",
"uri": "nickdora.a1-app.cf-app.com/admin",
"port":"8081"
}
],
"limits": {
"fds": 16384,
"mem": 1024,
"disk": 4096
}
}


Thanks,

Nick

4641 - 4660 of 9422