Date   

Re: Java Buildpack v3.1

James Bayer
 

that's quite a release! thanks to everyone who contributed. i really like
this list of packaged dependencies, that makes it very simple to see what's
inside.

On Thu, Jun 25, 2015 at 8:30 AM, Christopher Frost <cfrost(a)pivotal.io>
wrote:

I'm pleased to announce the release of the java-buildpack, version 3.1. This
release was focused on new monitoring frameworks and the Memory Calculator.
The Memory Calculator removes the need to restage an application after
scaling it's allocated memory. It has the following highlights:


- Dynatrace monitoring framework support. (via Stu Charlton
<https://github.com/cloudfoundry/java-buildpack/pull/187>)
- Introscope monitoring framework support.
- Memory calculator (via Mike Youngstrom, df007
<https://github.com/cloudfoundry/java-buildpack/issues/175>)
- Improved tar downloader (via Claude Devarenne
<https://github.com/cloudfoundry/java-buildpack/pull/195>)
- Improved OS detection (via Christopher Umbel
<https://github.com/cloudfoundry/java-buildpack/pull/185>)

For a more detailed look at the changes in 3.1, please take a look at the commit
log <https://github.com/cloudfoundry/java-buildpack/compare/v3.0...v3.1>.
Packaged versions of the buildpack, suitable for use with create-buildpack
and update-buildpack, can be found attached to this release
<https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.1>.
*Packaged Dependencies*

- AppDynamics Agent: 4.0.7_0
- GemFire 8.0.0
- GemFire Modules 8.0.0.1
- GemFire Modules Tomcat7 8.0.0.1
- GemFire Security 8.0.0
- Groovy: 2.4.3
- JRebel 6.2.1
- MariaDB JDBC: 1.1.9
- Memory Calculator (centos6): 1.1.1.RELEASE
- Memory Calculator (lucid): 1.1.1.RELEASE
- Memory Calculator (mountainlion): 1.1.1.RELEASE
- Memory Calculator (precise): 1.1.1.RELEASE
- Memory Calculator (trusty): 1.1.1.RELEASE
- New Relic Agent: 3.17.0
- OpenJDK JRE (centos6): 1.8.0_45
- OpenJDK JRE (lucid): 1.8.0_45
- OpenJDK JRE (mountainlion): 1.8.0_45
- OpenJDK JRE (precise): 1.8.0_45
- OpenJDK JRE (trusty): 1.8.0_45
- Play Framework JPA Plugin: 1.7.0.RELEASE
- PostgreSQL JDBC: 9.4.1201
- RedisStore: 1.2.0_RELEASE
- Spring Auto-reconfiguration: 1.7.0_RELEASE
- Spring Boot CLI: 1.2.4_RELEASE
- Tomcat Access Logging Support: 2.4.0_RELEASE
- Tomcat Lifecycle Support: 2.4.0_RELEASE
- Tomcat Logging Support: 2.4.0_RELEASE
- Tomcat: 8.0.23


Christopher Frost - Pivotal UK
Java Buildpack Team

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


Re: Soliciting feedback on a UX change for route services

Mike Youngstrom
 



This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be made
public facing. (Would require a broker to orchestrate stuff outside of CF
DNS, applying DoS security profiles to the route, force ssl on the front
end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be implemented
by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on a
route. Again could be implemented as a proxy if you trust X-Forwarded-For
or simply change some config on a front end load balancer no new proxy
needed.

Basically a service applied to a route could trigger and manage all kinds
of functionality not necessarily implemented as proxy orchestrated by the
GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike


Buildpacks ending lucid64 stack support

Mike Dalessio
 

Hi everyone,

The Buildpacks team just cut a series of releases removing lucid64 binaries
from the buildpacks.

*Background*

As announced earlier this year, the lucid64 stack ("rootfs") reached End of
Life on 20 April 2015
<http://fridge.ubuntu.com/2015/03/18/ubuntu-10-04-lucid-lynx-reaches-end-of-life-on-april-30-2015/>,
meaning that it no longer receives security updates after that date.

cf-release v211, released on 4 June 2014, removed the lucid64 stack from
Cloud Foundry, and Dieu's email from 6 June 2015
<http://lists.cloudfoundry.org/pipermail/cf-dev/2015-June/000348.html>
contains links
to application migration instructions.

During the Cloud Foundry Advisory Board meeting on 12 June 2015
<https://www.activestate.com/blog/2015/06/cloud-foundry-advisory-board-meeting-2015-june>,
it was noted that lucid64 support would be removed from the buildpacks in
the next few weeks.

*Releases*

The following Buildpacks were very recently released with lucid64 binary
support removed:

- go: 1.4.0
<https://github.com/cloudfoundry/go-buildpack/releases/tag/v1.4.0>
- nodejs: 1.4.0
<https://github.com/cloudfoundry/nodejs-buildpack/releases/tag/v1.4.0>
- php: 3.3.0
<https://github.com/cloudfoundry/php-buildpack/releases/tag/v3.3.0>
- python: 1.4.0
<https://github.com/cloudfoundry/python-buildpack/releases/tag/v1.4.0>
- ruby: 1.5.0
<https://github.com/cloudfoundry/ruby-buildpack/releases/tag/v1.5.0>
- staticfile: 1.2.0
<https://github.com/cloudfoundry/staticfile-buildpack/releases/tag/v1.2.0>

As a result, the php, python, ruby, and staticfile buildpacks are
significantly smaller than their previous versions.

We expect these versions will likely be in the next version of cf-release,
v213.

*Tooling to Package lucid64 Binaries*

Many CF operators may still be running the lucid64 stack. The same tooling
used to generate official buildpacks may be used by these operators to
package lucid64 binaries into their site-specific buildpacks to continue to
support lucid64 applications.

Each of these buildpacks' github repositories contains a file named
manifest-including-unsupported.yml, which contains metadata about Every
Version Of Everything, Ever. An example entry from the Ruby buildpack looks
like:

```

- name: ruby
version: 2.2.0
uri: https://pivotal-buildpacks.s3.amazonaws.com/ruby/binaries/lucid64/ruby-2.2.0.tgz
md5: 47e892bbaa2b08cf3c522a38c4c6755c
cf_stacks:
- lucid64

```

Copying the desired lucid64 entries from manifest-including-unsupported.yml
into manifest.yml and then running buildpack-packager with the
--use-custom-manifest argument will generate a buildpack that contains
lucid64 binaries.

Operators may also modify and use the Buildpack Runtime Acceptance Test
Suite <https://github.com/cloudfoundry/brats> ("BRATS") to test their
custom buildpacks. Instructions for doing this are out of scope for this
email, but feel free to contact me directly if you'd like to do so.


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.
Initially we're targeting support for one service per route, and
create-route/update-route accomplishes this simply. Associating multiple
services with a route isn't as simple as binding an app as they are not
independent. An order of chaining would have to be declared. In any case,
I'll admit that update-route doesn't scale well beyond a single service.
It's worth considering a UX that doesn't prevent predictable feature
enhancements.


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

On Thu, Jun 25, 2015 at 12:24 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

+1 for binding to a specific route (for all apps) instead of binding for
all routes of an app. One use-case that this will enable is
content-transformation service routers to only be applied on some specific
routes in order to be able measure their performance/latency impact before
extending them on other routes.

+1 for still being able to stack up multiple route services for a given
route (e.g. SSO, caching, and analytics)

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Shanon, can you please clarify that route services may still be bindeable
when this makes sense ?

For example, it might be useful for the apps bound with a router service
to be able to contact the router-service to send some control flow (e.g.
for the caching scenario to request a cache invalidation through HTCP
requests used in wikimedia
https://wikitech.wikimedia.org/wiki/Multicast_HTCP_purging
<https://www.google.com/url?q=https%3A%2F%2Fwikitech.wikimedia.org%2Fwiki%2FMulticast_HTCP_purging&sa=D&sntz=1&usg=AFQjCNGsGyNfYqsIugumSD-8L2tcjm4bXQ>
). In this case, the router services would be bound to apps that need to
control it.
Fair point, and thank you for the use case. Brokers have the option of
declaring whether a service is bindable or not in order to provide a better
user experience when services are not bindable (user receives a consistent
error message and no API call made to the broker). In CF we won't prevent a
service instance from being associated with a route AND an app. We'll pass
the route_service_url returned on provision to GoRouter, and any
credentials returned on bind to VCAP_SERVICES.


BTW, is there available updates on the router services model (i.e. route
service sending traffic back to the router, vs route services being exposed
to the app registry to send traffic to the app directly) ? Dieu mentionned
at the summit some pending discussions with Matt Stine around this topic
(and likely a service discovery / registry being exposed to route services
and apps), see detailed comment on the design document on section "other
proposals that were considered".
For mvp we're still planning for route services to forward requests back
through the LB and GoRouter.



Thanks,

Guillaume.


On Wed, Jun 24, 2015 at 10:51 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that
may not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax.
Would it be possible to bind more than one route service to a route with
that syntax? I'd prefer something like bind-route-service/unbind-route
service commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these
tweaks discussed here change the fundamental routing behavior we're
proposing. That is, that a route service url is associated with the route,
and not the app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

Interesting idea; I'll talk to Greg O about it.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Wed, Jun 24, 2015 at 11:49 PM, James Bayer <jbayer(a)pivotal.io> wrote:

*I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.*

i don't think this would be a backward incompatible change to introduce a
new cli command that only needs 1 argument while keeping the syntax for 2
arguments. the commands are distinguishable based on how many arguments
there are:

cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]
cf create-route DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

so in case 1, you override the currently targeted space with the one
specified on the cli command. in case 2, you just use whatever space is
targeted.

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that
may not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax.
Would it be possible to bind more than one route service to a route with
that syntax? I'd prefer something like bind-route-service/unbind-route
service commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these
tweaks discussed here change the fundamental routing behavior we're
proposing. That is, that a route service url is associated with the route,
and not the app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.
This is interesting. Could you flesh this out for me? What use cases do you
have in mind for associating a service instance with a route, but not
providing a forwarding address?


I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.
Good feedback. Initially we won't support chaining services, but it does
seem worth considering a UX that doesn't prevent us from supporting this in
the future.


I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Custom build pack [ failed to install WineHQ]

Mike Dalessio
 

There are ways to install .deb packages as a normal user, as exemplified by
the following Heroku buildpack:

https://github.com/ddollar/heroku-buildpack-apt/blob/master/bin/compile
(Please note that this buildpack will not work on CF without
modifications.) You may want to investigate a variation of this method.


However, it's also worth noting that there is a team, currently using a
blend of Pivotal, Centurylink and HP technology and developers, who are
close to releasing actual Windows support. You can see more about this
project, code-named "Greenhouse", here:

https://github.com/cloudfoundry-incubator/garden-windows

Cheers,
-mike


On Thu, Jun 25, 2015 at 12:21 PM, Pablo Alonso Rodriguez <
palonsoro(a)gmail.com> wrote:

I am sorry, but in order to run apt-get you need root privileges and you
do not have them inside a Warden container of a DEA. Processes run as
unprivileged user "vcap" who cannot gain root privileges in any way, as far
as I know.
In general, you should not rely on apt packages but use self-contained
software with as less dependencies as possible.
I hope this helps.
El 25/06/2015 12:56, "Balaramaraju JLSP" <balaramaraju(a)gmail.com>
escribió:


Hi All,

I am trying to create a custom build pack. To create a stack like WineHQ
with some VS2010 C++ Runtime to run windows native services.

BuildPack :-
bin/compile
#!/usr/bin/env bash echo "Install WineHQ"#wget
http://prdownloads.sourceforge.net/wine/wine-1.7.20.tar.bz2#tar -xjvf
wine-1.7.20.tar.bz2 && cd wine-1.7.*apt-get install wine1.7#./configure
--enable-win64#cd tools
#echo yes |./wineinstallecho "Update" echo "Load Custom Frameworks"echo "
Done"

but it failing with
-----> Downloaded app package (8.0K)
Cloning into '/tmp/buildpacks/WineHQ-BuildPack'...
Install WineHQ
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission
denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you
root?

any help is very much appreciated.

Thanks

J L S P Balaramaraju

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Custom build pack [ failed to install WineHQ]

Pablo Alonso Rodriguez <palonsoro@...>
 

I am sorry, but in order to run apt-get you need root privileges and you do
not have them inside a Warden container of a DEA. Processes run as
unprivileged user "vcap" who cannot gain root privileges in any way, as far
as I know.
In general, you should not rely on apt packages but use self-contained
software with as less dependencies as possible.
I hope this helps.

El 25/06/2015 12:56, "Balaramaraju JLSP" <balaramaraju(a)gmail.com> escribió:


Hi All,

I am trying to create a custom build pack. To create a stack like WineHQ
with some VS2010 C++ Runtime to run windows native services.

BuildPack :-
bin/compile
#!/usr/bin/env bash echo "Install WineHQ"#wget
http://prdownloads.sourceforge.net/wine/wine-1.7.20.tar.bz2#tar -xjvf
wine-1.7.20.tar.bz2 && cd wine-1.7.*apt-get install wine1.7#./configure
--enable-win64#cd tools
#echo yes |./wineinstallecho "Update" echo "Load Custom Frameworks"echo "
Done"

but it failing with
-----> Downloaded app package (8.0K)
Cloning into '/tmp/buildpacks/WineHQ-BuildPack'...
Install WineHQ
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission
denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you
root?

any help is very much appreciated.

Thanks

J L S P Balaramaraju

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Issues with offline ruby_buildpack, disconnected CF, and gems from Git

Josh Ghiloni
 

Hi all,

I’m currently working on a project where I have my gem source in our local git enterprise server, and I need to push an app that uses it to an instance of CF (v208) that is disconnected from the internet. The app has in its Gemfile a reference to that gem like this:

```
gem 'mygem', :git => 'https://github.myco.com/common/mygem.git'
```

When I run

```
bundle install
bundle package
```

That gem never shows up in my `vendor/cache` directory. However, if I use `bundle package --all`, it shows up in my `vendor/cache` directory as `vendor/cache/mygem-0.0.1-d1c2237f1ebca`. Unfortunately, when I `cf push`, the result is the same in both cases: my ruby app fails to find the require. I’m using the ruby buildpack v1.3, for what it’s worth. Also of note, this does run locally.

Is there something I can do to git ruby to recognize that this gem exists? I’m still rather new to Ruby and don’t fully understand the intricacies.

Josh Ghiloni
Senior Consultant
303.932.2202 o | 303.590.5427 m | 303.565.2794 f
jghiloni(a)ecsteam.com<mailto:jghiloni(a)ecsteam.com>

ECS Team
Technology Solutions Delivered
ECSTeam.com<http://ECSTeam.com>


Java Buildpack v3.1

Christopher Frost
 

I'm pleased to announce the release of the java-buildpack, version 3.1. This
release was focused on new monitoring frameworks and the Memory Calculator.
The Memory Calculator removes the need to restage an application after
scaling it's allocated memory. It has the following highlights:


- Dynatrace monitoring framework support. (via Stu Charlton
<https://github.com/cloudfoundry/java-buildpack/pull/187>)
- Introscope monitoring framework support.
- Memory calculator (via Mike Youngstrom, df007
<https://github.com/cloudfoundry/java-buildpack/issues/175>)
- Improved tar downloader (via Claude Devarenne
<https://github.com/cloudfoundry/java-buildpack/pull/195>)
- Improved OS detection (via Christopher Umbel
<https://github.com/cloudfoundry/java-buildpack/pull/185>)

For a more detailed look at the changes in 3.1, please take a look at
the commit
log <https://github.com/cloudfoundry/java-buildpack/compare/v3.0...v3.1>.
Packaged versions of the buildpack, suitable for use with create-buildpack
and update-buildpack, can be found attached to this release
<https://github.com/cloudfoundry/java-buildpack/releases/tag/v3.1>.
*Packaged Dependencies*

- AppDynamics Agent: 4.0.7_0
- GemFire 8.0.0
- GemFire Modules 8.0.0.1
- GemFire Modules Tomcat7 8.0.0.1
- GemFire Security 8.0.0
- Groovy: 2.4.3
- JRebel 6.2.1
- MariaDB JDBC: 1.1.9
- Memory Calculator (centos6): 1.1.1.RELEASE
- Memory Calculator (lucid): 1.1.1.RELEASE
- Memory Calculator (mountainlion): 1.1.1.RELEASE
- Memory Calculator (precise): 1.1.1.RELEASE
- Memory Calculator (trusty): 1.1.1.RELEASE
- New Relic Agent: 3.17.0
- OpenJDK JRE (centos6): 1.8.0_45
- OpenJDK JRE (lucid): 1.8.0_45
- OpenJDK JRE (mountainlion): 1.8.0_45
- OpenJDK JRE (precise): 1.8.0_45
- OpenJDK JRE (trusty): 1.8.0_45
- Play Framework JPA Plugin: 1.7.0.RELEASE
- PostgreSQL JDBC: 9.4.1201
- RedisStore: 1.2.0_RELEASE
- Spring Auto-reconfiguration: 1.7.0_RELEASE
- Spring Boot CLI: 1.2.4_RELEASE
- Tomcat Access Logging Support: 2.4.0_RELEASE
- Tomcat Lifecycle Support: 2.4.0_RELEASE
- Tomcat Logging Support: 2.4.0_RELEASE
- Tomcat: 8.0.23


Christopher Frost - Pivotal UK
Java Buildpack Team


Custom build pack [ failed to install WineHQ]

Balaramaraju JLSP <balaramaraju@...>
 

Hi All,

I am trying to create a custom build pack. To create a stack like WineHQ
with some VS2010 C++ Runtime to run windows native services.

BuildPack :-
bin/compile
#!/usr/bin/env bash echo "Install WineHQ"#wget
http://prdownloads.sourceforge.net/wine/wine-1.7.20.tar.bz2#tar -xjvf
wine-1.7.20.tar.bz2 && cd wine-1.7.*apt-get install wine1.7#./configure
--enable-win64#cd tools
#echo yes |./wineinstallecho "Update" echo "Load Custom Frameworks"echo "
Done"

but it failing with
-----> Downloaded app package (8.0K)
Cloning into '/tmp/buildpacks/WineHQ-BuildPack'...
Install WineHQ
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission
denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you
root?

any help is very much appreciated.

Thanks

J L S P Balaramaraju


Re: Soliciting feedback on a UX change for route services

Guillaume Berche
 

+1 for binding to a specific route (for all apps) instead of binding for
all routes of an app. One use-case that this will enable is
content-transformation service routers to only be applied on some specific
routes in order to be able measure their performance/latency impact before
extending them on other routes.

+1 for still being able to stack up multiple route services for a given
route (e.g. SSO, caching, and analytics)

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Shanon, can you please clarify that route services may still be bindeable
when this makes sense ?

For example, it might be useful for the apps bound with a router service to
be able to contact the router-service to send some control flow (e.g. for
the caching scenario to request a cache invalidation through HTCP requests
used in wikimedia https://wikitech.wikimedia.org/wiki/Multicast_HTCP_purging
<https://www.google.com/url?q=https%3A%2F%2Fwikitech.wikimedia.org%2Fwiki%2FMulticast_HTCP_purging&sa=D&sntz=1&usg=AFQjCNGsGyNfYqsIugumSD-8L2tcjm4bXQ>
). In this case, the router services would be bound to apps that need to
control it.

BTW, is there available updates on the router services model (i.e. route
service sending traffic back to the router, vs route services being exposed
to the app registry to send traffic to the app directly) ? Dieu mentionned
at the summit some pending discussions with Matt Stine around this topic
(and likely a service discovery / registry being exposed to route services
and apps), see detailed comment on the design document on section "other
proposals that were considered".

Thanks,

Guillaume.


On Wed, Jun 24, 2015 at 10:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: How to get files from crash apps

James Bayer
 

i'm not sure if this is the right property or not, maybe dieu knows:
https://github.com/cloudfoundry/cf-release/blob/master/jobs/dea_next/spec#L65-L67

On Wed, Jun 24, 2015 at 7:35 PM, Meng, Xiangyi <xiangyi.meng(a)emc.com> wrote:

I am using DEA. But I didn’t found where the container was kept. Is it
compressed and stored somewhere? I also took a look at
/var/vcap/data/dea_next/crashes/id, it only contain the files in “logs”
directory: staging_task.log/stdout.log/stderr.log/env.log, not application
files. We need the files under “app” directory. Also I tried to access
warden as you said. But the warden under /var/vcap/data/warden/depot was
removed immediately after application process was killed.







*From:* cf-dev-bounces(a)lists.cloudfoundry.org [mailto:
cf-dev-bounces(a)lists.cloudfoundry.org] *On Behalf Of *James Bayer
*Sent:* 2015年6月24日 16:07
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] How to get files from crash apps



if you're using DEA's i believe the container stays around on the DEA for
about an hour or so by default before being removed.



assuming you're on a DEA, to investigate, you'd need to know the DEA and
the warden handle to investigate, log in to the DEA as an operator with
bosh, then go the warden depot directory, find the warden handle and
execute bin/wsh from the container handle directory.



see:
http://docs.cloudfoundry.org/running/troubleshooting/troubleshooting-apps.html#access-warden



in diego, removing containers happens right away, but diego is also going
to support ssh for active troubleshooting and could just increase the
memory and attach jvm tools for debugging purposes to troubleshoot.



good luck.



On Tue, Jun 23, 2015 at 1:12 AM, Meng, Xiangyi <xiangyi.meng(a)emc.com>
wrote:

We encountered java out of memory issue in our CF env recently. We had
enabled gc log for the application by setting JAVA_TOOL_OPTIONS:
-Xloggc:gc.log. But when out of memory issue occurred, the application was
stopped and removed. We can’t get gc.log. Is there any way to keep the
gc.log after application crashes? The CF version we are using is 197. Any
advice would be appreciated.



Regards,

Maggie


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev





--

Thank you,



James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Re: Soliciting feedback on a UX change for route services

James Bayer
 

*I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.*

i don't think this would be a backward incompatible change to introduce a
new cli command that only needs 1 argument while keeping the syntax for 2
arguments. the commands are distinguishable based on how many arguments
there are:

cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]
cf create-route DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

so in case 1, you override the currently targeted space with the one
specified on the cli command. in case 2, you just use whatever space is
targeted.

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Re: How to get files from crash apps

MaggieMeng
 

I am using DEA. But I didn’t found where the container was kept. Is it compressed and stored somewhere? I also took a look at /var/vcap/data/dea_next/crashes/id, it only contain the files in “logs” directory: staging_task.log/stdout.log/stderr.log/env.log, not application files. We need the files under “app” directory. Also I tried to access warden as you said. But the warden under /var/vcap/data/warden/depot was removed immediately after application process was killed.



From: cf-dev-bounces(a)lists.cloudfoundry.org [mailto:cf-dev-bounces(a)lists.cloudfoundry.org] On Behalf Of James Bayer
Sent: 2015年6月24日 16:07
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] How to get files from crash apps

if you're using DEA's i believe the container stays around on the DEA for about an hour or so by default before being removed.

assuming you're on a DEA, to investigate, you'd need to know the DEA and the warden handle to investigate, log in to the DEA as an operator with bosh, then go the warden depot directory, find the warden handle and execute bin/wsh from the container handle directory.

see: http://docs.cloudfoundry.org/running/troubleshooting/troubleshooting-apps.html#access-warden

in diego, removing containers happens right away, but diego is also going to support ssh for active troubleshooting and could just increase the memory and attach jvm tools for debugging purposes to troubleshoot.

good luck.

On Tue, Jun 23, 2015 at 1:12 AM, Meng, Xiangyi <xiangyi.meng(a)emc.com<mailto:xiangyi.meng(a)emc.com>> wrote:
We encountered java out of memory issue in our CF env recently. We had enabled gc log for the application by setting JAVA_TOOL_OPTIONS: -Xloggc:gc.log. But when out of memory issue occurred, the application was stopped and removed. We can’t get gc.log. Is there any way to keep the gc.log after application crashes? The CF version we are using is 197. Any advice would be appreciated.

Regards,
Maggie

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org<mailto:cf-dev(a)lists.cloudfoundry.org>
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev



--
Thank you,

James Bayer


Re: Soliciting feedback on a UX change for route services

Mike Youngstrom
 

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like services.
Binding a service to a route is as good away as any to start users thinking
that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would prefer
use of a user-provided service to keep the relationships consistent, the
parameters generic (not specific to USPIs), and limit the number of ways to
accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: Soliciting feedback on a UX change for route services

Shannon Coen
 

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like example.com?
this cli pattern above does not really allow for that right? perhaps it's
better to have a similar syntax to the existing route commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would prefer
use of a user-provided service to keep the relationships consistent, the
parameters generic (not specific to USPIs), and limit the number of ways to
accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


cf-release v212 is now available

Dieu Cao <dcao@...>
 

Apologies for the delayed release notes. Currently travelling in the UK.
So sunny!

-----

The cf-release v212 was released on June 22nd, 2015

- IMPORTANT: Database migrations have been moved into their own job.
Previously part of cloud_controller_ng details
<https://www.pivotaltracker.com/story/show/92724718>
- IMPORTANT: Loggregator vms have been renamed Doppler details
<https://www.pivotaltracker.com/story/show/89420698>. Note: with
zero-downtime requires a two-phase deploy:
1. Add instances of each doppler job to match the number of instances
of the corresponding loggregator job and deploy.
2. Remove all instances of loggregator and deploy.
- IMPORTANT: default template stemcells have been updated from lucid to
trusty details <https://www.pivotaltracker.com/story/show/95647916>

Buildpacks

- cloudfoundry/cf-release #701
<https://github.com/cloudfoundry/cf-release/pull/701> Upgrade NodeJs
buildpack to v1.3.4 details
<https://www.pivotaltracker.com/story/show/96491602>
- cloudfoundry/cf-release #697
<https://github.com/cloudfoundry/cf-release/pull/697> Upgrade PHP
buildpack to v3.2.2 details
<https://www.pivotaltracker.com/story/show/96125988>
- cloudfoundry/cf-release #699
<https://github.com/cloudfoundry/cf-release/pull/699> Upgrade Staticfile
buildpack to v1.1.0 details
<https://www.pivotaltracker.com/story/show/96330780>
- cloudfoundry/cf-release #702
<https://github.com/cloudfoundry/cf-release/pull/702> Upgrade Python
buildpack to v1.3.5 details
<https://www.pivotaltracker.com/story/show/96496744>

Runtime

- Allow for more than one attribute to be updated in a service instance
update call. If anything fails, roll back all changes. details
<https://www.pivotaltracker.com/n/projects/969486/stories/95209044>
- Warden more gracefully handles "Disconnected" timeouts during staging
details
<https://www.pivotaltracker.com/n/projects/966314/stories/95632950>
- Fixed a bug where newrelic filled logs with bogus error: ERROR :
URI::InvalidURIError: bad URI details
<https://www.pivotaltracker.com/story/show/95284888>
- [Experimental] User can scale v3 applications process memory details
<https://www.pivotaltracker.com/story/show/92367324>
- Address cve USN-2624-1 <http://www.ubuntu.com/usn/usn-2624-1/> details
<https://www.pivotaltracker.com/story/show/96304108>
1. Upgraded installed packages
- Service catalog now reports plans with the duplicate name details
<https://www.pivotaltracker.com/story/show/96240038>
- [Experimental] User can scale v3 process disk details
<https://www.pivotaltracker.com/story/show/92367410>
- Service catalog now reports duplicate plan ids details
<https://www.pivotaltracker.com/n/projects/1211680/stories/96728362>
- Fixed bug where Cloud Controller would become stuck waiting for NFS
details <https://www.pivotaltracker.com/story/show/94152506>
- Fixed bug where apps could request negative disk details
<https://www.pivotaltracker.com/story/show/96771020>
- Added doppler_logging_endpoint to /v2/info details
<https://www.pivotaltracker.com/story/show/93047998>
- Applications can be scaled to 0 instances details
<https://www.pivotaltracker.com/story/show/94063170>
- Space manager and auditor should see 404 error when deleting service
keys details
<https://www.pivotaltracker.com/n/projects/1211680/stories/96753978>
- Gorouter - Added "Cache-Control" and "Expires" headers to prevent
caching of heartbeat responses. details
<https://www.pivotaltracker.com/n/projects/1358110/stories/96503820>
- Fixed a bug where buildpack caches were not being deleted details
<https://www.pivotaltracker.com/story/show/95652208>
- Removed Experimental tag from context path routing details
<https://www.pivotaltracker.com/story/show/>

UAA

- Bumped UAA to version 3.2.1 details
<https://github.com/cloudfoundry/uaa/releases/tag/2.3.1>

Routing Api

- [Experimental] Now co-located on the Cloud Controller details
<https://www.pivotaltracker.com/story/show/91732492>

Loggregator

- No major changes besides the rename to doppler mentioned above

Manifest and Job Spec Changes

- properties.doppler.enabled details
<https://www.pivotaltracker.com/n/projects/966314/stories/93047998>
- properties.doppler.use_ssl details
<https://www.pivotaltracker.com/n/projects/966314/stories/93047998>
- properties.doppler.port details
<https://www.pivotaltracker.com/n/projects/966314/stories/93047998>
- properties.collector.memory_threshold details
<https://www.pivotaltracker.com/story/show/95479064>
- properties.uaa.newrelic.environment can be used to configure the old
newrelic configuration of uaa.newrelic.common.license_key details
<https://github.com/cloudfoundry/cf-release/pull/703>
- properties.uaa.database.case_insensitive can be set to *true* when
using case sensitivity with queries/filters because your DB is case
sensitive.
- [Experimental] routing api properties
- properties.routing-api.consul_ttl
- properties.routing-api.lock_retry_interval
- properties.routing-api.metrics_reporting_ttl
- properties.routing-api.statsd_endpoint
- properties.routing-api.debug_address
- properties.routing-api.max_concurrent_etcd_requests
- properties.routing-api.statsd_client_flush_interval
- [Experimental]
- properties.routing-api.enabled changed to
properties.router.enable_routing_api
- properties.acceptance_tests.oauth_password cats credentials used to
create, list and update routes details
<https://www.pivotaltracker.com/story/show/93734082>
- properties.acceptance_tests.system_domain cats system domain for
your CF releasedetails
<https://www.pivotaltracker.com/story/show/93734082>

Used Configuration

- BOSH Version: 152
- Stemcell Version: 2989
- CC Api Version: 2.29.0

Commit summary
<http://htmlpreview.github.io/?https://github.com/cloudfoundry-community/cf-docs-contrib/blob/master/release_notes/cf-212-whats-in-the-deploy.html>
Compatible Diego Version

- final release 0.1304.0 commit
<https://github.com/cloudfoundry-incubator/diego-release/commit/6e2004e611047da34520652cf021ffad1baed068>


https://github.com/cloudfoundry/cf-release/releases/tag/v212


Re: CfSummit slides

Guillaume Berche
 

Thanks for the update to [1], this really helps to have access to slides
speakers shared.

Regards,

Guillaume.

[1] http://www.cfsummit.com/program/slides


On Wed, Jun 17, 2015 at 12:24 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

no worries, thanks for your help Craig

Guillaume.

On Wed, Jun 17, 2015 at 12:44 AM, C. Craig Ross <ccr(a)linuxfoundation.org>
wrote:

Hi Guillaume,

Regrettably there was some confusion and some speakers submitted them
slides via the CFP system instead of emailing them. The former is the
normal behavior for the majority of our events but the CF Summit slides
needed to be uploaded separately by our events team.

We will get your slides and the others up on the site in the next 24hrs.
Our apologies for the trouble and thanks for bringing this to our attention.

Cheers,

C.

On Tue, Jun 16, 2015 at 6:12 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thank Angela for your response. I wonder whether the CFP system is
properly listing speaker submitted slides, as for example my two sessions
indeed have their slides attached to their associated proposal [1-4], and
they don't yet appear into [5].

Are there some other speakers on the cf-dev list that had their slides
posted on the cfp system and don't yet see them published onto [5] ?

Thanks,

Guillaume.

[1]
http://events.linuxfoundation.org/sites/events/files/slides/orange_case_study_0.pdf
[2] http://events.linuxfoundation.org/cfp/proposals/5249/4719
[3]
http://events.linuxfoundation.org/sites/events/files/slides/adapting_cf_to_org_reqs.pdf
[4] http://events.linuxfoundation.org/cfp/proposals/5249/4721
[5] http://www.cfsummit.com/program/slides

Guillaume.


On Thu, Jun 11, 2015 at 1:42 AM, CF Events <events(a)cloudfoundry.org>
wrote:

Hello Guillaume,

On Wed, Jun 10, 2015 at 5:09 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Hi,

Thanks again to the CF Foundation for the great cf summit, and for
publishing so promptly the video recordings on youtube. The sessions
content is great to watch, and I'm sometimes lacking the high resolution
slides display, and ability to use the slides as a reference.

There is currently 12 slide decks onto [1] over the 38 sessions
presented. Is there somewhere else they can be accessed, or any way for the
foundation to publish the ones speakers have already posted on the CFP
system ?
I will double check with our content manager, but typically if slides
are missing it is because the speakers did not share the with us. If we do
still have some that have not been posted, I'll make sure that happens by
Monday.

Thank you,

Angela


Thanks in advance,

Guillaume.

[1] http://www.cfsummit.com/program/slides


--
Cloud Foundry Summit Events Team
Cloud Foundry Foundation
events(a)cloudfoundry.org

--
C. Craig Ross
Director of Creative Services & Developer Programs
The Linux Foundation
http://www.linuxfoundation.org/

8861 - 8880 of 9421