Date   

Re: SSH access to CF app instances on Diego

Matthew Sykes <matthew.sykes@...>
 

My concern is the default behavior.

When I first prototyped this support in February, I never expected that
merely accessing a container would cause it to be terminated. As we can see
from Jan's response, it's completely unexpected; many others have the same
reaction.

I do not believe that this behavior should be part of the default
configuration and I do believe the control needs to be at the space level.
I have have already expressed this opinion during Diego retros and at the
runtime PMC meeting.

I honestly believe that if we were talking about applying this behavior to
`bosh ssh` and `bosh scp`, few would even consider running in a 'kill on
taint mode' because of how useful it is. We should learn from that.

If this behavior becomes the default, I think our platform will be seen as
moving from opinionated to parochial. That would be unfortunate.

On Thu, Jun 25, 2015 at 6:05 PM, James Bayer <jbayer(a)pivotal.io> wrote:

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com> wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that instance
will
be restarted.
What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
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

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


Re: Soliciting feedback on a UX change for route services

Guillaume Berche
 

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting

Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs that
end up being associated with the app that receive the associated traffic
(e.g. cache hit or cache miss for a specific incoming request). With route
services being associated to routes (and not being bound to app instances
anymore), I'd like to re-iterate the suggestion I made in the design
document (on Feb 17) to have the gorouter include the app_id in the headers
of the signed request it sends to route service(s). This will allow for a
route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.

On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


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

_______________________________________________
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: service discovery

Sumanth Yamala
 

No. My endpoints don't change. I envision having a number of 12 factor stateless applications getting deployed using CF push (java buildpacks). Some of these stateless apps need to talk to each other and so the need for service discovery.


Currently we use Consul - i.e. each 12 factor app registers itself with Consul and apps needs to re-discover another app. We feed in the Consul end point to all the apps as an environment variable.


Using environment variables has a dependency issue that certain applications that have not been started yet, would not be visible to applications that have already started...but a HashMap of apps and its route could itself serve as a repository to discover other applications as long as the app can get access to the hash map or we persist this hash map as a KV store in Consul.


Thanks all for your inputs.


Sumanth



________________________________
From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of James Bayer <jbayer(a)pivotal.io>
Sent: Thursday, June 25, 2015 11:42 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] service discovery

can you describe the architecture of your applications? do the endpoints change often after some mircoservices have been started?

your app needs some way to look up other network endpoints it needs. there are several ways to do this.

* use environment variables - which is provided just-in-time when the container starts - this might be a URL for example, that routes to the CF router that might be bound to several different apps, but all the source app needs to know is the destination route represented by a FQDN and optional context path

* use a service - either user a service broker or provided service that provides information to the apps that bind to it, might be a URL and authentication information, this information is also put in the apps env variables

* use something like the spring cloud config service that can distribute information to clients dynamically post container start [1]

* use something like the spring cloud eureka service from netflix oss that can provide dynamic information to clients using netflix ribbon, also takes in updates post container start [2] [3]

[1] https://www.youtube.com/watch?v=bJvReWt2jLc
[2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html
[3] http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry

On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:

micro-service architecture.


Yes - would like for applications to discover the URL of other applications deployed in CF . Consul is what I use right now - was wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a database, Consul..can it be used for stateless components as well?



Thanks,

Sumanth


________________________________
From: cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org> <cf-dev-bounces(a)lists.cloudfoundry.org<mailto:cf-dev-bounces(a)lists.cloudfoundry.org>> on behalf of John Wong <gokoproject(a)gmail.com<mailto:gokoproject(a)gmail.com>>
Sent: Thursday, June 25, 2015 10:35 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] service discovery

What's the requirement that your application need to discover other application? Did you mean somethibg like say microservice architecture and you want to know the url available and any metadat / property of some service / app you depend on? One way is via service broker. You can use also use consul and token to do ACL based resource retrieval/discovery and I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:

Hi,


In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth


--
Sent from Jeff Dean's printf() mobile console

_______________________________________________
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: service discovery

James Bayer
 

can you describe the architecture of your applications? do the endpoints
change often after some mircoservices have been started?

your app needs some way to look up other network endpoints it needs. there
are several ways to do this.

* use environment variables - which is provided just-in-time when the
container starts - this might be a URL for example, that routes to the CF
router that might be bound to several different apps, but all the source
app needs to know is the destination route represented by a FQDN and
optional context path

* use a service - either user a service broker or provided service that
provides information to the apps that bind to it, might be a URL and
authentication information, this information is also put in the apps env
variables

* use something like the spring cloud config service that can distribute
information to clients dynamically post container start [1]

* use something like the spring cloud eureka service from netflix oss that
can provide dynamic information to clients using netflix ribbon, also takes
in updates post container start [2] [3]

[1] https://www.youtube.com/watch?v=bJvReWt2jLc
[2] http://cloud.spring.io/spring-cloud-netflix/spring-cloud-netflix.html
[3]
http://blog.pivotal.io/pivotal-cloud-foundry/features/deploying-microservice-architectures-with-pivotal-cloud-foundry

On Thu, Jun 25, 2015 at 7:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

micro-service architecture.


Yes - would like for applications to discover the URL of other
applications deployed in CF . Consul is what I use right now - was
wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a
database, Consul..can it be used for stateless components as well?



Thanks,

Sumanth


------------------------------
*From:* cf-dev-bounces(a)lists.cloudfoundry.org <
cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of John Wong <
gokoproject(a)gmail.com>
*Sent:* Thursday, June 25, 2015 10:35 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] service discovery

What's the requirement that your application need to discover other
application? Did you mean somethibg like say microservice architecture and
you want to know the url available and any metadat / property of some
service / app you depend on? One way is via service broker. You can use
also use consul and token to do ACL based resource retrieval/discovery and
I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote:

Hi,


In CF space - the applications that get deployed in warden containers -
how do they discover other applications ? Should we pick a third party
like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth

--
Sent from Jeff Dean's printf() mobile console

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


--
Thank you,

James Bayer


Re: service discovery

John Wong
 

Service brokers I thought are only for stateful components like a
database, Consul..can it be used for stateless components as well?
Well here is a way to look at it. You can have consul to discover a bunch
of cassandra nodes in a cluster, and you can remove a node from ever being
contacted by your application if said node is not responsive. Another
example is nginx behind ha proxy or a bunch of apps behind ha proxy, and
you can remove app/webservers went down from ha proxy config dynamically
with some consul engineering.

So what exactly makes something stateless in your case? I think if you can
provide us a concrete use case that'd be very helpful (because you can do
stateless with like DNS load balancing / behind ELB / HA Proxy etc).

John

On Thu, Jun 25, 2015 at 10:47 PM, Sumanth Yamala <Sumanth.Yamala(a)sas.com>
wrote:

micro-service architecture.


Yes - would like for applications to discover the URL of other
applications deployed in CF . Consul is what I use right now - was
wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a
database, Consul..can it be used for stateless components as well?



Thanks,

Sumanth


------------------------------
*From:* cf-dev-bounces(a)lists.cloudfoundry.org <
cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of John Wong <
gokoproject(a)gmail.com>
*Sent:* Thursday, June 25, 2015 10:35 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
*Subject:* Re: [cf-dev] service discovery

What's the requirement that your application need to discover other
application? Did you mean somethibg like say microservice architecture and
you want to know the url available and any metadat / property of some
service / app you depend on? One way is via service broker. You can use
also use consul and token to do ACL based resource retrieval/discovery and
I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote:

Hi,


In CF space - the applications that get deployed in warden containers -
how do they discover other applications ? Should we pick a third party
like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth

--
Sent from Jeff Dean's printf() mobile console

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


Re: Document for service broker api version 2.5

James Bayer
 

looks like the docs are only at 2.4:
http://docs.cloudfoundry.org/services/api.html

2.5 should only have been incremental changes and should be backward
compatible with other 2.x versions.

when you say it doesn't work, do you have details of an interaction that
shows the problem?

On Thu, Jun 25, 2015 at 7:45 PM, NGUYEN Hong Chau <nguyenhongchau(a)gmail.com>
wrote:

Hi all,

I'm trying to implement a service broker for cf-release v210. I
implemented my service broker in cf-release v207 based on this service
broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code doesn't
work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?

Thanks in advance.

--
Nguyen Hong-Chau

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


--
Thank you,

James Bayer


Re: Java Buildpack v3.1

Christopher B Ferris <chrisfer@...>
 

+1

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Cloud
IBM Software Group, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: http://thoughtsoncloud.com/index.php/author/cferris/
phone: +1 508 667 0402

On Jun 25, 2015, at 4:46 PM, James Bayer <jbayer(a)pivotal.io> wrote:

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)
Introscope monitoring framework support.
Memory calculator (via Mike Youngstrom, df007)
Improved tar downloader (via Claude Devarenne)
Improved OS detection (via Christopher Umbel)
For a more detailed look at the changes in 3.1, please take a look at the commit log. Packaged versions of the buildpack, suitable for use with create-buildpack and update-buildpack, can be found attached to this release.

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
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Re: service discovery

Sumanth Yamala
 

micro-service architecture.


Yes - would like for applications to discover the URL of other applications deployed in CF . Consul is what I use right now - was wondering if CloudFoundry had something in this space.


Service brokers I thought are only for stateful components like a database, Consul..can it be used for stateless components as well?

?

Thanks,

Sumanth


________________________________
From: cf-dev-bounces(a)lists.cloudfoundry.org <cf-dev-bounces(a)lists.cloudfoundry.org> on behalf of John Wong <gokoproject(a)gmail.com>
Sent: Thursday, June 25, 2015 10:35 PM
To: Discussions about Cloud Foundry projects and the system overall.
Subject: Re: [cf-dev] service discovery

What's the requirement that your application need to discover other application? Did you mean somethibg like say microservice architecture and you want to know the url available and any metadat / property of some service / app you depend on? One way is via service broker. You can use also use consul and token to do ACL based resource retrieval/discovery and I have seen this apptoach (actually today at a local tech talk).
On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com<mailto:Sumanth.Yamala(a)sas.com>> wrote:

Hi,


In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth


--
Sent from Jeff Dean's printf() mobile console


Document for service broker api version 2.5

NGUYEN Hong Chau <nguyenhongchau@...>
 

Hi all,

I'm trying to implement a service broker for cf-release v210. I implemented
my service broker in cf-release v207 based on this service broker project
<https://github.com/cloudfoundry-community/spring-boot-cf-service-broker>.
Now cf-release v210 using api version 2.5 for broker and my code doesn't
work. I'm looking up docs for api version 2.5 but find no document
available yet. Does anyone implement a service broker for api version 2.5?
And could you explain me the modifications I must do for the new broker
version?

Thanks in advance.

--
Nguyen Hong-Chau


Re: service discovery

John Wong
 

What's the requirement that your application need to discover other
application? Did you mean somethibg like say microservice architecture and
you want to know the url available and any metadat / property of some
service / app you depend on? One way is via service broker. You can use
also use consul and token to do ACL based resource retrieval/discovery and
I have seen this apptoach (actually today at a local tech talk).

On Thursday, June 25, 2015, Sumanth Yamala <Sumanth.Yamala(a)sas.com> wrote:

Hi,


In CF space - the applications that get deployed in warden containers -
how do they discover other applications ? Should we pick a third party
like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth
--
Sent from Jeff Dean's printf() mobile console


service discovery

Sumanth Yamala
 

Hi,


In CF space - the applications that get deployed in warden containers - how do they discover other applications ? Should we pick a third party like Consul or Eureka, or does CF provide an alternate approach.


Thanks in advance.


Thanks,

Sumanth


Re: How to get files from crash apps

Jack Cai
 

I shared one simple technique in this slide [1], see Page 20. Basically you
can add ";sleep 1d" to the start command of your application, to keep the
container around for one day. You can remove the "--no-route" option if
your application listens on the HTTP port in time during start up.

Jack

[1]
https://www.slideshare.net/greensight/10-common-errors-when-pushing-apps-to-cloud-foundry

On Thu, Jun 25, 2015 at 2:58 AM, James Bayer <jbayer(a)pivotal.io> wrote:

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

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


Re: SSH access to CF app instances on Diego

James Bayer
 

you can turn the "restart tainted containers" feature off with
configuration if you are authorized to do so. then using scp to write files
into a container would be persisted for the lifetime of the container even
after the ssh session ends.

On Thu, Jun 25, 2015 at 5:50 PM, Jan Dubois <jand(a)activestate.com> wrote:

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that instance
will
be restarted.
What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan
_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev
--
Thank you,

James Bayer


Re: SSH access to CF app instances on Diego

Jan Dubois <jand@...>
 

On Thu, Jun 25, 2015 at 5:36 PM, Eric Malm <emalm(a)pivotal.io> wrote:
after executing a command, concluding an
interactive session, or copying a file into an instance, that instance will
be restarted.
What is the purpose of being able to copy a file into an instance if
the instance is restarted as soon as the file has been received?

Cheers,
-Jan


SSH access to CF app instances on Diego

Eric Malm <emalm@...>
 

Dear CF community,

I'm pleased to announce that the Diego team is nearing completion of our
initial track of work to enable SSH access to app instances running on
Diego. We've recently published some preliminary versions of the Diego-SSH
CLI plugin at https://github.com/cloudfoundry-incubator/diego-ssh/releases,
and I've posted some instructions for developers and operators in the Diego
Design Notes, at
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/ssh-access-and-policy.md
.

For a CF+Diego deployment with SSH already enabled and publicly routable,
accessing a CF app instance over SSH is as simple as running cf ssh
<app-name> after installing the CLI plugin. The plugin also supports a -i
option to target other instance indices and a -L option to forward local
ports, and we expect to add a cf scp command soon as well for bidirectional
file transfer.

It's also possible to use the built-in ssh and scp clients on Linux and OS
X to access instances. For more details on how to use those clients, please
see the design notes linked above or the more extensive documentation for
the CF and Diego authenticators on the Diego-SSH repository:
https://github.com/cloudfoundry-incubator/diego-ssh.

If you're using the steps in the diego-release README
<https://github.com/cloudfoundry-incubator/diego-release/blob/develop/README.md>
to deploy it and CF to BOSH-Lite, this SSH functionality should all just
work for you automatically. If you're operating on a different
infrastructure, you will have a few values to configure in your BOSH
deployment manifests, and, depending on your environment, a load balancer
to provision in front of Diego's SSH proxies. Again, the design notes cover
the basic manifest properties and infrastructure setup required to give
access to CF app instances.

Version 0.1.2 of the Diego-SSH plugin also provides commands for adjusting
the SSH policy on CF apps and spaces through Cloud Controller. In
particular, users can employ those commands to enable and disable SSH both
on an individual app and on an entire space. Operators can separately
choose whether to allow SSH access via a BOSH-configurable parameter in
Cloud Controller's configuration.

Finally, we realize that unfettered SSH access to instances is something of
a double-edged sword: while it enables interactive inspection and
experimentation inside an app instance, it also makes it possible to build
'snowflake' instances that will melt whenever the platform restarts them.
To prevent the creation of such snowflakes, we propose to implement a
restart policy for CF app instances: after executing a command, concluding
an interactive session, or copying a file into an instance, that instance
will be restarted. Forwarding ports and copying files out will not trigger
a restart, though. Cloud Controller admins will be able to opt individual
spaces out of this restart behavior, to allow developers greater inspection
of and experimentation on their apps in those spaces. We haven't yet
introduced this behavior, but it's among the last pieces of work we intend
to do before we consider this initial batch of SSH work complete.

If you're interested in the progress of the remaining stories we currently
have planned for SSH access, please look for them in the Diego tracker
<https://www.pivotaltracker.com/n/projects/1003146> with the 'ssh' label.


Thanks,
Eric Malm, CF Runtime Diego PM


Re: Soliciting feedback on a UX change for route services

Mike Youngstrom
 

Thanks Shannon,

Though James' suggestion would work if the the service bound to a route
doesn't use a proxy then the order become irrelevant. It would be
inconvenient to have to list all of the services bound to a route every
time I wanted to add or remove a route service.

I would propose something along the lines of the way buildpack position is
managed.

#Bind Route Service
cf bind-route-service DOMAIN SERVICE [-n HOST] [-i POSITION]

#List route services and their current order
cf route-services DOMAIN [-n HOST]

Then the user can specify a position if it is important to them but use the
default if they don't care.

Mike

On Thu, Jun 25, 2015 at 4:04 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


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

_______________________________________________
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
 

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:


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

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


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.

8821 - 8840 of 9398