Date   

cloudfoundry file descriptor limit is too small

peter huang
 

Hi, All,
My cloudfoundry version is 225, when i run some java spring-boot program in the cf, sometime it will throw the "too many files open" exception, i know it is about the file limit.
So i login to the runner, and use `ulimit -n` to see, they are 1024, but i found in the warden .\cf-release-225\jobs\dea_next\templates\dea_ctl.erb
it call `ulimit -n 4096`, looks like it doesn't work.
and in .\cf-release-225\packages\dea_next\dea_next\vendor\cache\warden-181b550918c8\warden\spec\container\linux_spec.rb
Line 1418: response = client.run(:handle => handle, :script => "ulimit -n", :rlimits => rlimits)
no sure it will overwrite the exist one(i don't know ruby)
my question is, does they some way to expand the size of limit ? or we need to upgrade the cloudfoundry?
Thanks,
Peter


Runtime PMC - Persi Project Lead

Dieu Cao <dcao@...>
 

Hello all,

Ted Young, the Project Lead for the Persi team within the Runtime PMC, last
day at Pivotal was this past week. We wish him all the best in his future
endeavors and thank him for his time with us.

Dell would like to nominate Julian Hjortshoj for the Project Lead for the
Persi team.

Julian joined the Diego Persistence team as a software developer in April.
During his 25-odd year career making software he has served in various
technical leadership roles (manager, project lead, architect). Prior to
joining CF, Julian worked for the ECM division of Dell/EMC as the
application/ui architect for a suite of Cloud Foundry deployed content
management applications.

If there are any questions/objections to this appointment, please send that
to me by end of day October 27, 2016.

-Dieu Cao

Runtime PMC Lead


Contribute mongodb 3.X bosh release

Lynn Lin
 

All,
Previously we from DELL-EMC use MongoDB service 2.X from this project under cloudfoundry community https://github.com/cloudfoundry-community/cf-services-contrib-release . Months ago we want to use mongoDB 3.X which improves performance a lot however we don’t find the available mongoDB 3.X under cloudfoundy github so our team developed MongoDB 3.X bosh release and provide additional cluster support compared to https://github.com/cloudfoundry-community/cf-services-contrib-release . This version is deployed to production site and running for quite a while , it looks stable . Who should we contact to start conversation to see how we can contribute back for this bosh mongoDB 3.X release if it is worth



Thanks
Lynn Lin


Re: CF environmental variables - org is missing

Vinod Singh <vinoddandy@...>
 

Hi Jaison,

If CF team can include app_name+space+org in Loggregator logs, that would
solve many of our use cases. The current application id is created at
runtime and external systems finding difficult to segregate message based
on application id.

Do we have any blog item to include app_name in loggregator messages ?

Regards,
Vinod

On Tue, Oct 18, 2016 at 8:03 AM, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi Jason,

For example, when connecting to the database we set the client application
name on the connection.
If the db becomes heavily loaded, the db admin can check the expensive
statements view and see which applications generate them.
Also for end to end tracing when a transaction goes through multiple
components, we have to record each involved component name.
So we need an application name that is human readable and unique.

Best regards,
Petar


On Tue, Oct 18, 2016 at 12:39 AM, Jason Sherron <jsherron(a)pivotal.io>
wrote:

Hi Peter,

Can you detail your supportability needs for external services? I'm
wondering if this is something that could be filtered at the network level
and if that might help. We're building ways to identify and filter network
traffic sources by application. It wouldn't include arbitrary text like
org/space, but would be mapped to an application via an identifier and
perhaps IP address.

Jason - Container Networking


On Mon, Oct 17, 2016 at 1:26 PM Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi,

We have the same issue.
For supportability reasons we need the app to identify itself when
connecting to external services.
application_id is not suitable in this case as the operator/admin cannot
easily decipher it.
It would be best to identify the app using org_name + space_name +
app_name.
All of these are present in VCAP_APPLICATION except org_name.
Is it omitted intentionally? If not, can it be added?

Best regards,
Peter


On Thu, Oct 13, 2016 at 6:19 PM, Vinod Singh <vinoddandy(a)gmail.com>
wrote:

Friends,

I am working to retrieve org/space/application-name in CF via System
provided environmental variables.
Unfortunately I could not "org" in list. Is it not a good idea to
include "org" also in System Provided list ?

cf env <appname>

System-Provided:


{
"VCAP_APPLICATION": {
"application_id": "74b3e1a6-ba9f-4dcb-9ae3-e68e1dbfa417",
"application_name": "mylogapp",
"application_uris": [
"xxxx.xxxx.xxx"
],
"application_version": "e43c2d12-cd8e-46d3-9298-ce0905651c0e",
"limits": {
"disk": 1024,
"fds": 16384,
"mem": 128
},
"name": "mylogapp",
"space_id": "4d942c57-e41e-43e2-ba3a-0665ceaa976b",
"space_name": "demo2",
"uris": [
"xxxxx.xxxxx.xxxxx"
],
"users": null,
"version": "e43c2d12-cd8e-46d3-9298-ce0905651c0e"
}
}


Regards,
Vinod



cf-release Submodule Path Recursion Error (and fix!)

Chunyi Lyu <clyu@...>
 

We've seen an issue with ./scripts/update in cf-release. If you have a
sufficiently old version of `cf-release`, and then you try to run the
update script, you'll get an error that looks like this:
```
Failed to recurse into submodule path 'src/consul-release'
```
Here are the steps to reproduce:
- `git clone https://github.com/cloudfoundry/cf-release`
- `git checkout 58f89c63b1cd673df34ca98302e4573ed60c1bf3`
- `git submodule update --init --recursive`
- `git checkout develop`
- `./scripts/update`
You should see the error at this point.

If you hit this, we've got three fixes for you.

First and potentially simplest, just run one more git submodule sync
--recursive && ./scripts/update after the failure.

If that doesn't work, you can either delete and re-clone cf-release from
scratch, or go edit your git modules:
Edit `git/modules/src/consul-release/modules/src/confab/vendor/
github.com/hashicorp/serf/config`, so that it's remote url points to `
https://github.com/cloudfoundry-incubator/serf` instead of `
https://github.com/hashicorp/serf`.

Hopefully this won't have inconvenienced too many of you!

Regards-
-Jesse Alford && Chunyi Lyu
CF Release Integration Team


Re: How to run cronjobs with Application

Anuj Jain <anuj17280@...>
 

Thanks Nick I will try it

On 19 Oct 2016 8:21 a.m., "Nicholas Calugar" <ncalugar(a)pivotal.io> wrote:

Hi Anuj,

For scheduling, you might want to look into the Advanced Python Scheduler
[1]. You would push the scheduler as a separate app to Cloud Foundry.

You could also experiment with V3 Tasks that we are close to releasing.
You can think of Tasks as commands to run against your app code that only
take up resources while executing. As of CF-245, you can push an
application and then run a task against it. There’s currently only support
via curl [2], but we are working on supporting this via CLI.


[1] http://apscheduler.readthedocs.io/en/3.0/
[2] http://v3-apidocs.cloudfoundry.org/version/release-candidate/#push-v2-
app-and-run-a-v3-task


Thanks,

Nick

--
Nicholas Calugar

On October 18, 2016 at 8:03:38 AM, Anuj Jain (anuj17280(a)gmail.com) wrote:

Hi,


We have an application (lets say django app) - which we deployed on
Cloud Foundry - now there are few commands which we want to run
periodically (cron jobs) - what is the best way to handle this with Cloud
Foundry.



Thanks

- Anuj


Re: How to run cronjobs with Application

Nicholas Calugar
 

Hi Anuj,

For scheduling, you might want to look into the Advanced Python Scheduler
[1]. You would push the scheduler as a separate app to Cloud Foundry.

You could also experiment with V3 Tasks that we are close to releasing. You
can think of Tasks as commands to run against your app code that only take
up resources while executing. As of CF-245, you can push an application and
then run a task against it. There’s currently only support via curl [2],
but we are working on supporting this via CLI.


[1] http://apscheduler.readthedocs.io/en/3.0/
[2]
http://v3-apidocs.cloudfoundry.org/version/release-candidate/#push-v2-app-and-run-a-v3-task


Thanks,

Nick

--
Nicholas Calugar

On October 18, 2016 at 8:03:38 AM, Anuj Jain (anuj17280(a)gmail.com) wrote:

Hi,


We have an application (lets say django app) - which we deployed on
Cloud Foundry - now there are few commands which we want to run
periodically (cron jobs) - what is the best way to handle this with Cloud
Foundry.



Thanks

- Anuj


Contribute mongodb 3.X bosh release

Lin, Lynn <Lynn.X.Lin@...>
 

All,
Previously we use MongoDB service 2.X from this project under cloudfoundry community https://github.com/cloudfoundry-community/cf-services-contrib-release . Months ago we want to use mongoDB 3.X which improves performance a lot however we don't find the available mongoDB 3.X under cloudfoundy github so peter,huang (cc'ed) developed MongoDB 3.X bosh release and provide additional cluster support compared to https://github.com/cloudfoundry-community/cf-services-contrib-release . This version is deployed to production site and running for quite a while , it looks stable . Who should we contact to start conversation to see how we can contribute back for this bosh mongoDB 3.X release if it is worth



Thanks
Lynn


Re: UAA Standalone Deployment

Sree Tummidi
 

Hi Abhishek,

As part of Pivotal deployments UAA is being used to secure both the
platform and Apps running on the platform.
Our hosted Cloud Foundry deployment (aka Pivotal Web Services) is running
on AWS has two UAA instances handling a load of 20-30 requests per second
per instance. You need to scale the UAA instances depending on your
concurrency requirements.

Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry

On Tue, Oct 18, 2016 at 3:21 PM, Siva Balan <mailsiva(a)gmail.com> wrote:

Hi Abhishek,
Yes, you should be able to use UAA outside of CF and integrate it with any
IdP of your choice. At GE we have UAA deployed on CF and our performance
numbers are CF based. The numbers should not be very different on a non-CF
env. Attached pdf should give you some performance numbers from our tests

-Siva

On Tue, Oct 18, 2016 at 3:04 PM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

+ Siva & Ilya from GE

Can you please help.

Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry


On Tue, Oct 18, 2016 at 11:43 AM, abhishek jain <intelccdodemo(a)gmail.com>
wrote:

Hi

Can we use UAA outside cloud foundry as standalone service with LDAP or
any other social networking provider ? Where can i find performance bench
marking related statistics on UAA service ?

Thank you

--
http://www.twitter.com/sivabalans


Re: UAA Standalone Deployment

Siva Balan <mailsiva@...>
 

Hi Abhishek,
Yes, you should be able to use UAA outside of CF and integrate it with any
IdP of your choice. At GE we have UAA deployed on CF and our performance
numbers are CF based. The numbers should not be very different on a non-CF
env. Attached pdf should give you some performance numbers from our tests

-Siva

On Tue, Oct 18, 2016 at 3:04 PM, Sree Tummidi <stummidi(a)pivotal.io> wrote:

+ Siva & Ilya from GE

Can you please help.

Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry


On Tue, Oct 18, 2016 at 11:43 AM, abhishek jain <intelccdodemo(a)gmail.com>
wrote:

Hi

Can we use UAA outside cloud foundry as standalone service with LDAP or
any other social networking provider ? Where can i find performance bench
marking related statistics on UAA service ?

Thank you


Re: UAA Standalone Deployment

Sree Tummidi
 

+ Siva & Ilya from GE

Can you please help.

Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry


On Tue, Oct 18, 2016 at 11:43 AM, abhishek jain <intelccdodemo(a)gmail.com>
wrote:

Hi

Can we use UAA outside cloud foundry as standalone service with LDAP or
any other social networking provider ? Where can i find performance bench
marking related statistics on UAA service ?

Thank you


UAA Standalone Deployment

abhishek jain <intelccdodemo@...>
 

Hi

Can we use UAA outside cloud foundry as standalone service with LDAP or any
other social networking provider ? Where can i find performance bench
marking related statistics on UAA service ?

Thank you


NOTICE: Default version of Go in the Go Buildpack will change to 1.7.x after 2016-11-18

Stephen Levine
 

Hi All,

The version of Go in the Go Buildpack will change from version 1.6.3 to the
latest 1.7.x version (currently 1.7.2) in the first release of the Go
Buildpack after November 18, 2016. If you would like to continue using Go
1.6.3, please set the $GOVERSION environment variable in your app, or use
your choice of Go dependency management utility to lock your version of Go
to 1.6.3. For more information, refer to the documentation:
http://docs.cloudfoundry.org/buildpacks/go/

Thank you,
Stephen Levine
CF Buildpacks PM


How to run cronjobs with Application

Anuj Jain <anuj17280@...>
 

Hi,


We have an application (lets say django app) - which we deployed on
Cloud Foundry - now there are few commands which we want to run
periodically (cron jobs) - what is the best way to handle this with Cloud
Foundry.



Thanks

- Anuj


Re: CF environmental variables - org is missing

Peter Dotchev <dotchev@...>
 

Hi Jason,

For example, when connecting to the database we set the client application
name on the connection.
If the db becomes heavily loaded, the db admin can check the expensive
statements view and see which applications generate them.
Also for end to end tracing when a transaction goes through multiple
components, we have to record each involved component name.
So we need an application name that is human readable and unique.

Best regards,
Petar

On Tue, Oct 18, 2016 at 12:39 AM, Jason Sherron <jsherron(a)pivotal.io> wrote:

Hi Peter,

Can you detail your supportability needs for external services? I'm
wondering if this is something that could be filtered at the network level
and if that might help. We're building ways to identify and filter network
traffic sources by application. It wouldn't include arbitrary text like
org/space, but would be mapped to an application via an identifier and
perhaps IP address.

Jason - Container Networking


On Mon, Oct 17, 2016 at 1:26 PM Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi,

We have the same issue.
For supportability reasons we need the app to identify itself when
connecting to external services.
application_id is not suitable in this case as the operator/admin cannot
easily decipher it.
It would be best to identify the app using org_name + space_name +
app_name.
All of these are present in VCAP_APPLICATION except org_name.
Is it omitted intentionally? If not, can it be added?

Best regards,
Peter


On Thu, Oct 13, 2016 at 6:19 PM, Vinod Singh <vinoddandy(a)gmail.com>
wrote:

Friends,

I am working to retrieve org/space/application-name in CF via System
provided environmental variables.
Unfortunately I could not "org" in list. Is it not a good idea to include
"org" also in System Provided list ?

cf env <appname>

System-Provided:


{
"VCAP_APPLICATION": {
"application_id": "74b3e1a6-ba9f-4dcb-9ae3-e68e1dbfa417",
"application_name": "mylogapp",
"application_uris": [
"xxxx.xxxx.xxx"
],
"application_version": "e43c2d12-cd8e-46d3-9298-ce0905651c0e",
"limits": {
"disk": 1024,
"fds": 16384,
"mem": 128
},
"name": "mylogapp",
"space_id": "4d942c57-e41e-43e2-ba3a-0665ceaa976b",
"space_name": "demo2",
"uris": [
"xxxxx.xxxxx.xxxxx"
],
"users": null,
"version": "e43c2d12-cd8e-46d3-9298-ce0905651c0e"
}
}


Regards,
Vinod



Re: Garden-RunC is 1.0! (& ACTION REQUIRED: End-of-life for garden-linux)

Dieu Cao <dcao@...>
 

Congrats to the Garden teams! Super excited about this step forward!

-Dieu

On Mon, Oct 17, 2016 at 8:46 PM, Dr Nic Williams <drnicwilliams(a)gmail.com>
wrote:

Lovely. All our bosh-lites are upgraded and happy to be running another
v1+ release!





On Tue, Oct 18, 2016 at 10:23 AM +1100, "Christopher B Ferris" <
chrisfer(a)us.ibm.com> wrote:

Congrats!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402 <+1%20508%20667%200402>

On Oct 18, 2016, at 1:27 AM, Julz Friedman <julz.friedman(a)gmail.com>
wrote:

Hi cf-dev,

This is a very exciting email to write! I'm extremely proud to announce
that garden-runC <https://github.com/cloudfoundry/garden-runc-release>,
the new cloud foundry container runtime for Linux, based on the OCI
specification <https://github.com/opencontainers/runtime-spec> and its
reference implementation “runC <https://github.com/opencontainers/runc>”,
is now 1.0!

ACTION REQUIRED: Given that garden-runc is now ready to use and fully
compatible with garden-linux, we intend to end-of-life garden-linux
immediately. More details on this and an explanation for the accelerated
timescale are at the bottom of this email.

About garden-runc: At this point garden-runC has been successfully
running 100% of the production traffic on PWS for around a month (it has
been running a smaller portion of the load for a longer time as we gained
confidence). The Diego team has been testing with and listing compatible
releases <https://github.com/cloudfoundry/diego-cf-compatibility> of
both g-l and g-r for several months. It has also been the only supported
linux backend for concourse for several months, thereby being used in a
broad range of environments and deployment scenarios. In all cases it has
held up remarkably well. Given this I'm happy to recommend people move over
to garden-runC as soon as possible (diego’s manifest generation scripts
should make this extremely simple -- just pass the `-g` flag to diego
manifest generation
<https://github.com/cloudfoundry/diego-release/blob/develop/docs/manifest-generation.md#-g-opt-into-using-garden-runc-release-for-cells>
-- but please note you MUST recreate any cells that previously ran
garden-linux as part of the transition or you WILL have problems. An easy
way to do this is to combine the transition to garden-runc with a stemcell
deploy).

As well as being based on open standards and using a low-level container
runtime developed with a large community and many eyeballs, garden-runC has
some other significant benefits:


-

AppArmor <https://wiki.ubuntu.com/AppArmor> is configured and
enforced by default and out of the box for all unprivileged containers.
-

Seccomp whitelisting is used to restrict the set of system calls
<https://github.com/cloudfoundry/guardian/blob/master/guardiancmd/seccomp.go>
a container can access, hugely reducing the surface area for break-out
exploits. Again this is set up out of the box, you don't need to do
anything.
-

We've been able to simplify and modularise the garden code base
extensively as part of this transition, allowing pluggable networking and
rootfs management. This enables (and will be required by) the
fast-developing container-to-container networking work
<https://github.com/cloudfoundry-incubator/netman-release> and the
new “grootfs” OCI-compliant rootfs downloader
<https://github.com/cloudfoundry/grootfs-release>
-

Garden-runC uses the exact same low-level container execution code as
docker/k8s for running containers, so when you run container images you
know they run identically in CF as elsewhere


I'm immensely proud of the cross-foundation team that has delivered this,
including engineers from Pivotal, IBM and SAP.

GARDEN-LINUX END OF LIFE: 28/10/2016 - ACTION REQUIRED: Now that
garden-runC is ready we’re extremely keen to avoid maintaining two
code-bases for any longer than necessary, so we would like to move everyone
to garden-runC immediately, with the next Diego-release update (as
mentioned above, apart from the need to recreate the cells this is a 1-1
transition). Doing this on an accelerated timescale is particularly
important because we have encountered a regression in the 4.4 kernel that
causes problems during container destruction for garden-linux. We are
working to track this down, but it is proving extremely difficult to
rectify or work around. If anyone intends to use stemcells with 4.4
kernels, until we identify a fix, they should immediately move to
garden-runC to avoid issues.

If anyone has huge problems moving off garden-linux now please reach out
to me asap and we’ll see what we can do, otherwise I will suggest diego
stop supporting generating manifests for garden-linux with the next
release, and will propose moving garden-linux to the attic shortly after
that. Either way, we will no longer be developing new features for
garden-linux or accepting pull requests from this point. Unless anyone
has a strong reason otherwise (if so please do say!), we will end support
for garden-linux 28/10/2016.

Thanks all very much, and again a huge thanks to the garden team!

Julz Friedman
Garden Core PM



Re: Garden-RunC is 1.0! (& ACTION REQUIRED: End-of-life for garden-linux)

Dr Nic Williams <drnicwilliams@...>
 

Lovely. All our bosh-lites are upgraded and happy to be running another v1+ release!

On Tue, Oct 18, 2016 at 10:23 AM +1100, "Christopher B Ferris" <chrisfer(a)us.ibm.com> wrote:










Congrats!
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
On Oct 18, 2016, at 1:27 AM, Julz Friedman <julz.friedman(a)gmail.com> wrote:



Hi cf-dev,


This is a very exciting email to write! I'm extremely proud to announce that garden-runC, the new cloud foundry container runtime for Linux, based on the OCI specification and its reference implementation “runC”, is now 1.0!


ACTION REQUIRED: Given that garden-runc is now ready to use and fully compatible with garden-linux, we intend to end-of-life garden-linux immediately. More details on this and an explanation for the accelerated timescale are at the bottom of this email.


About garden-runc: At this point garden-runC has been successfully running 100% of the production traffic on PWS for around a month (it has been running a smaller portion of the load for a longer time as we gained confidence). The Diego team has been testing with and listing compatible releases of both g-l and g-r for several months. It has also been the only supported linux backend for concourse for several months, thereby being used in a broad range of environments and deployment scenarios. In all cases it has held up remarkably well. Given this I'm happy to recommend people move over to garden-runC as soon as possible (diego’s manifest generation scripts should make this extremely simple -- just pass the `-g` flag to diego manifest generation -- but please note you MUST recreate any cells that previously ran garden-linux as part of the transition or you WILL have problems. An easy way to do this is to combine the transition to garden-runc with a stemcell deploy).


As well as being based on open standards and using a low-level container runtime developed with a large community and many eyeballs, garden-runC has some other significant benefits:


AppArmor is configured and enforced by default and out of the box for all unprivileged containers.

Seccomp whitelisting is used to restrict the set of system calls a container can access, hugely reducing the surface area for break-out exploits. Again this is set up out of the box, you don't need to do anything.

We've been able to simplify and modularise the garden code base extensively as part of this transition, allowing pluggable networking and rootfs management. This enables (and will be required by) the fast-developing container-to-container networking work and the new “grootfs” OCI-compliant rootfs downloader

Garden-runC uses the exact same low-level container execution code as docker/k8s for running containers, so when you run container images you know they run identically in CF as elsewhere


I'm immensely proud of the cross-foundation team that has delivered this, including engineers from Pivotal, IBM and SAP.


GARDEN-LINUX END OF LIFE: 28/10/2016 - ACTION REQUIRED: Now that garden-runC is ready we’re extremely keen to avoid maintaining two code-bases for any longer than necessary, so we would like to move everyone to garden-runC immediately, with the next Diego-release update (as mentioned above, apart from the need to recreate the cells this is a 1-1 transition). Doing this on an accelerated timescale is particularly important because we have encountered a regression in the 4.4 kernel that causes problems during container destruction for garden-linux. We are working to track this down, but it is proving extremely difficult to rectify or work around. If anyone intends to use stemcells with 4.4 kernels, until we identify a fix, they should immediately move to garden-runC to avoid issues.


If anyone has huge problems moving off garden-linux now please reach out to me asap and we’ll see what we can do, otherwise I will suggest diego stop supporting generating manifests for garden-linux with the next release, and will propose moving garden-linux to the attic shortly after that. Either way, we will no longer be developing new features for garden-linux or accepting pull requests from this point. Unless anyone has a strong reason otherwise (if so please do say!), we will end support for garden-linux 28/10/2016.


Thanks all very much, and again a huge thanks to the garden team!
Julz FriedmanGarden Core PM


Re: Helping with Stack Overflow activity on Cloud Foundry and BOSH

Sree Tummidi
 

Thank you Amit !

Thanks,
Sree Tummidi
Staff Product Manager
Identity - Pivotal Cloud Foundry


On Mon, Oct 17, 2016 at 5:20 PM, Etourneau Gwenn <gwenn.etourneau(a)gmail.com>
wrote:

Thanks. Will check this out

2016-10-18 7:43 GMT+09:00 Amit Gupta <agupta(a)pivotal.io>:

Hey folks,

In the last few months there's been a noticeable growth in activity on
Stack Overflow related to Cloud Foundry questions. Folks who are active on
the cf-dev and cf-bosh mailing lists may be interested in helping out on
Stack Overflow as well, so I thought I'd share a tool I use to track to get
email notifications for SO activity.

1. Go to https://stackexchange.com/filters and log in the way you
normally would for any stackexchange site such as StackOverflow (or sign up
if you don't already have an account).
2. Click on *New filter.*
3. In section 1, select *Just questions tagged with the* cloudfoundry *tag
on...* All Sites, and click *Add rule*.
4. Repeat the above step with other tags such as cloudfoundry-uaa and
bosh. You could also add your favourite vendor distributions here
such as pivotal-cloud-foundry, ibm-bluemix, swisscomdev, etc.
5. In section 2, name your filter, e.g. Cloud Foundry.
6. In section 3, check the box to say *Yes, send to *<your-email> and
choose your frequency every 15 minutes / every 3 hours / every day.
7. Click *Save Changes*.

Happy StackOverflowing!

Best,
Amit


Re: Helping with Stack Overflow activity on Cloud Foundry and BOSH

Etourneau Gwenn
 

Thanks. Will check this out

2016-10-18 7:43 GMT+09:00 Amit Gupta <agupta(a)pivotal.io>:

Hey folks,

In the last few months there's been a noticeable growth in activity on
Stack Overflow related to Cloud Foundry questions. Folks who are active on
the cf-dev and cf-bosh mailing lists may be interested in helping out on
Stack Overflow as well, so I thought I'd share a tool I use to track to get
email notifications for SO activity.

1. Go to https://stackexchange.com/filters and log in the way you
normally would for any stackexchange site such as StackOverflow (or sign up
if you don't already have an account).
2. Click on *New filter.*
3. In section 1, select *Just questions tagged with the* cloudfoundry *tag
on...* All Sites, and click *Add rule*.
4. Repeat the above step with other tags such as cloudfoundry-uaa and
bosh. You could also add your favourite vendor distributions here
such as pivotal-cloud-foundry, ibm-bluemix, swisscomdev, etc.
5. In section 2, name your filter, e.g. Cloud Foundry.
6. In section 3, check the box to say *Yes, send to *<your-email> and
choose your frequency every 15 minutes / every 3 hours / every day.
7. Click *Save Changes*.

Happy StackOverflowing!

Best,
Amit


Re: Garden-RunC is 1.0! (& ACTION REQUIRED: End-of-life for garden-linux)

Christopher B Ferris <chrisfer@...>
 

Congrats!

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer(a)us.ibm.com
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

On Oct 18, 2016, at 1:27 AM, Julz Friedman <julz.friedman(a)gmail.com> wrote:

Hi cf-dev,

This is a very exciting email to write! I'm extremely proud to announce that garden-runC, the new cloud foundry container runtime for Linux, based on the OCI specification and its reference implementation “runC”, is now 1.0!

ACTION REQUIRED: Given that garden-runc is now ready to use and fully compatible with garden-linux, we intend to end-of-life garden-linux immediately. More details on this and an explanation for the accelerated timescale are at the bottom of this email.

About garden-runc: At this point garden-runC has been successfully running 100% of the production traffic on PWS for around a month (it has been running a smaller portion of the load for a longer time as we gained confidence). The Diego team has been testing with and listing compatible releases of both g-l and g-r for several months. It has also been the only supported linux backend for concourse for several months, thereby being used in a broad range of environments and deployment scenarios. In all cases it has held up remarkably well. Given this I'm happy to recommend people move over to garden-runC as soon as possible (diego’s manifest generation scripts should make this extremely simple -- just pass the `-g` flag to diego manifest generation -- but please note you MUST recreate any cells that previously ran garden-linux as part of the transition or you WILL have problems. An easy way to do this is to combine the transition to garden-runc with a stemcell deploy).

As well as being based on open standards and using a low-level container runtime developed with a large community and many eyeballs, garden-runC has some other significant benefits:

AppArmor is configured and enforced by default and out of the box for all unprivileged containers.
Seccomp whitelisting is used to restrict the set of system calls a container can access, hugely reducing the surface area for break-out exploits. Again this is set up out of the box, you don't need to do anything.
We've been able to simplify and modularise the garden code base extensively as part of this transition, allowing pluggable networking and rootfs management. This enables (and will be required by) the fast-developing container-to-container networking work and the new “grootfs” OCI-compliant rootfs downloader
Garden-runC uses the exact same low-level container execution code as docker/k8s for running containers, so when you run container images you know they run identically in CF as elsewhere

I'm immensely proud of the cross-foundation team that has delivered this, including engineers from Pivotal, IBM and SAP.

GARDEN-LINUX END OF LIFE: 28/10/2016 - ACTION REQUIRED: Now that garden-runC is ready we’re extremely keen to avoid maintaining two code-bases for any longer than necessary, so we would like to move everyone to garden-runC immediately, with the next Diego-release update (as mentioned above, apart from the need to recreate the cells this is a 1-1 transition). Doing this on an accelerated timescale is particularly important because we have encountered a regression in the 4.4 kernel that causes problems during container destruction for garden-linux. We are working to track this down, but it is proving extremely difficult to rectify or work around. If anyone intends to use stemcells with 4.4 kernels, until we identify a fix, they should immediately move to garden-runC to avoid issues.

If anyone has huge problems moving off garden-linux now please reach out to me asap and we’ll see what we can do, otherwise I will suggest diego stop supporting generating manifests for garden-linux with the next release, and will propose moving garden-linux to the attic shortly after that. Either way, we will no longer be developing new features for garden-linux or accepting pull requests from this point. Unless anyone has a strong reason otherwise (if so please do say!), we will end support for garden-linux 28/10/2016.

Thanks all very much, and again a huge thanks to the garden team!

Julz Friedman
Garden Core PM

3501 - 3520 of 9398