Hi All - We're proposing prioritizing work among all core Cloud Foundry
components to move necessary locks from a shared distributed data store
into components’ own data stores and allow for generic DNS based service
discovery. This is in response to operational difficulties with Consul as
well as seeing multiple places where app availability has depended on
Consul.

Please see the Locks & Service Discovery in CF Runtime
<https://docs.google.com/document/d/16O5Rk5tOmHc2Qeya7soVHoASAgrH9jYZ0V3fS58dY14/edit>
proposal
for more details and discussion.

Matthew Kocher
Sr. Director of Engineering, Cloud Foundry @ Pivotal

Hi,

For detailed info, you have to iterate over app endpoint for each app in
space.

Thanks
Ronak

Thanks for your quick response paolo but the apps call(/v2/spaces/$space-id/apps) will not give any information about instances like this
https://apidocs.cloudfoundry.org/242/apps/get_the_instance_information_for_a_started_app.html.

Hi,
You can query /v2/spaces/$space-id/apps.

BR,

Paolo

Hi,

We are interested in getting app instance details for all apps within a space. space summary '/v2/spaces/50ae42f6-346d-4eca-9e97-f8c9e04d5fbe/summary' call gives only info about 'running_instances' and 'instances', but not about instance status such as RUNNING, STARTING and so on.
So is there any way where we can achieve this with a single API call ??

Hi All -

In an effort to improve the organization of Loggregator components we are planning to move a couple repos out of the main loggregator repo. The first is the statsd-injector. If you happen to reference the statsd-injector repo you'll need to update to the new locations referenced below before February 1st. I'll send out a reminder January 31st for all you procrastinators out there.

New statsd-injector repos -
https://github.com/cloudfoundry/statsd-injector
https://github.com/cloudfoundry/statsd-injector-release

If you have any concerns about this repo by February 1st moving please let me know.

Thanks Guillaume. We should have a couple presentations as well and updates
from team. Will send other reminders soon.

Best,

Max

On Mon, Jan 16, 2017 at 10:29 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Max, I've added some questions to the google agenda, maybe we can
also go through previously unanswered questions prepared by the community
for past meeting.

Guillaume.

On Wed, Jan 11, 2017 at 12:45 AM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Please note that the first CAB call of 2017 is next Wednesday,
January 18th @ 8a PST.

I had to change the schedule a bit since the previous Google Calendar
expired. I added a link to the new calendar [1] as well as the agenda [2]
below.

Please go to slack.cloudfoundry.org and join the #CAB channel for
previous and future discussions. Post any comments and questions there as
well.

Finally, please nominate projects, yourself, or others for presentations.
Feel free to connect with me directly so I add you to schedule.

Talk to you all next week. We'll send one more email reminder on this
list.

Best,

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone

[1] https://calendar.google.com/calendar/event?action=TEMPLA
TE&tmeid=bm01NnQ0a25oaW5pZjNycDFxamNkanQzOTBfMjAxNzAxMThUMTY
wMDAwWiBtbWF4aW1pbGllbkBt&tmsrc=mmaximilien%40gmail.com

[2] https://docs.google.com/document/d/1SCOlAquyUmNM-AQnekCO
XiwhLs6gveTxAcduvDcW_xI

--
max
http://maximilien.org
http://blog.maximilien.com

Thanks Max, I've added some questions to the google agenda, maybe we can
also go through previously unanswered questions prepared by the community
for past meeting.

Guillaume.

On Wed, Jan 11, 2017 at 12:45 AM, Michael Maximilien <maxim(a)us.ibm.com>
wrote:

Hi, all,

Please note that the first CAB call of 2017 is next Wednesday,
January 18th @ 8a PST.

I had to change the schedule a bit since the previous Google Calendar
expired. I added a link to the new calendar [1] as well as the agenda [2]
below.

Please go to slack.cloudfoundry.org and join the #CAB channel for
previous and future discussions. Post any comments and questions there as
well.

Finally, please nominate projects, yourself, or others for presentations.
Feel free to connect with me directly so I add you to schedule.

Talk to you all next week. We'll send one more email reminder on this list.

Best,

dr.max
ibm cloud labs
sillicon valley, ca

Sent from my iPhone

[1] https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=
bm01NnQ0a25oaW5pZjNycDFxamNkanQzOTBfMjAxNzAxMThUMTYwMDAwWiBt
bWF4aW1pbGllbkBt&tmsrc=mmaximilien%40gmail.com

[2] https://docs.google.com/document/d/1SCOlAquyUmNM-
AQnekCOXiwhLs6gveTxAcduvDcW_xI

Please include me, Hristo. Thank you!

— Casey

Hi all,

We are planning an inception on January 31st from 10am PST.

We invite everyone interested to take a look at the proposal [1], provide feedback, and join us at the inception meeting.

If you want to attend, please reply to me directly so I can send invites with the connection details.

Regards,
Hristo Iliev

[1] https://docs.google.com/document/d/1zGYi0jGRX9kodn8WR8OHn6CSjo3BTorfuza121aIeuU/edit?usp=sharing

Hi Dies,

You'd probably need to set the following properties in your cf-release
manifest:

router.enable_ssl: true

router.ssl_cert: <cert from ha_proxy.ssl_pem>
router.ssl_key: <key from ha_proxy.ssl_pem>

Best,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, Jan 13, 2017 at 3:10 PM, Koper, Dies <diesk(a)fast.au.fujitsu.com>
wrote:

Hi Shannon,



For a simple bosh-lite user like me, not used to modifying the manifest
stubs, is there an easy way on my default (Virtualbox) bosh-lite deployment
to try out using CF without HAProxy, to see if it has any impact on what I
do?



I tried adding the following to my /etc/hosts file as a test, but `cf
login` failed with a “dial tcp 10.244.0.138:443: getsockopt: connection
refused” – I

Do I need to manually edit the manifest and copy over the bosh-lite
wildcard certificate into the gorouter section and enable its tsl
termination, and maybe also remove any restrictions in place on IP
addressed connections are accepted from?



10.244.0.22 api.bosh-lite.com

10.244.0.22 uaa.bosh-lite.com

10.244.0.22 login.bosh-lite.com

10.244.0.22 doppler.bosh-lite.com

10.244.0.22 loggregator.bosh-lite.com

10.244.0.22 ssh.bosh-lite.com



Regards,

Dies Koper





*From:* Shannon Coen [mailto:scoen(a)pivotal.io]
*Sent:* Saturday, January 14, 2017 7:26 AM
*To:* Cloud Foundry Dev
*Subject:* [cf-dev] Considering deprecation of the HAProxy in cf-release



Over that past year or two, CF teams have been extracting components from
cf-release into their own BOSH releases. This allows teams to innovate more
quickly. These releases are currently submoduled into cf-release, so that
cf-release can be used to deploy the full suite of core CF services. The
current plan is that cf-release will eventually be deprecated in favor of
cf-deployment <https://github.com/cloudfoundry/cf-deployment>, a
toolchain that generates a manifest for CF from these composable releases.



One of the last components in cf-release
<https://github.com/cloudfoundry/cf-release/tree/master/jobs> that has
not been extracted into its own release is HAProxy.



Historically, HAProxy has fulfilled two use cases: load balancing and TLS
termination. Since support for TLS termination was added to Gorouter, load
balancing may be the remaining use case.



In production environments, operators are expected to provide their own
redundant load balancers and configure them to forward requests to the CF
routers. HAProxy may provide a convenience where another load balancer is
not available, but as HAProxy is not inherently highly available in a
production environment it would require another load balancer in front of
it for HA, at which point HAProxy itself would be superfluous. For this
reason we have not recommended use of the HAProxy in cf-release for
production environments.



This leaves the use case of development, or lab environments. Over the
past year, we have begun thinking that the HAProxy provides no additional
value here either. Since HA is not required in these environments, we
have begun recommending
<http://docs.cloudfoundry.org/adminguide/configure-lb-healthcheck.html>
that operators point DNS directly at single instances of the CF Router and
SSH Proxy.



Therefore, we're proposing deprecation of the HAProxy in cf-release. Of
course, we want to hear your feedback. If you are currently leveraging the
HAProxy in cf-release, please share your use cases.



Thank you,


Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

Hi Shannon,

For a simple bosh-lite user like me, not used to modifying the manifest stubs, is there an easy way on my default (Virtualbox) bosh-lite deployment to try out using CF without HAProxy, to see if it has any impact on what I do?

I tried adding the following to my /etc/hosts file as a test, but `cf login` failed with a “dial tcp 10.244.0.138:443: getsockopt: connection refused” – I
Do I need to manually edit the manifest and copy over the bosh-lite wildcard certificate into the gorouter section and enable its tsl termination, and maybe also remove any restrictions in place on IP addressed connections are accepted from?

10.244.0.22 api.bosh-lite.com
10.244.0.22 uaa.bosh-lite.com
10.244.0.22 login.bosh-lite.com
10.244.0.22 doppler.bosh-lite.com
10.244.0.22 loggregator.bosh-lite.com
10.244.0.22 ssh.bosh-lite.com

Regards,
Dies Koper


From: Shannon Coen [mailto:scoen(a)pivotal.io]
Sent: Saturday, January 14, 2017 7:26 AM
To: Cloud Foundry Dev
Subject: [cf-dev] Considering deprecation of the HAProxy in cf-release

Over that past year or two, CF teams have been extracting components from cf-release into their own BOSH releases. This allows teams to innovate more quickly. These releases are currently submoduled into cf-release, so that cf-release can be used to deploy the full suite of core CF services. The current plan is that cf-release will eventually be deprecated in favor of cf-deployment<https://github.com/cloudfoundry/cf-deployment>, a toolchain that generates a manifest for CF from these composable releases.

One of the last components in cf-release<https://github.com/cloudfoundry/cf-release/tree/master/jobs> that has not been extracted into its own release is HAProxy.

Historically, HAProxy has fulfilled two use cases: load balancing and TLS termination. Since support for TLS termination was added to Gorouter, load balancing may be the remaining use case.

In production environments, operators are expected to provide their own redundant load balancers and configure them to forward requests to the CF routers. HAProxy may provide a convenience where another load balancer is not available, but as HAProxy is not inherently highly available in a production environment it would require another load balancer in front of it for HA, at which point HAProxy itself would be superfluous. For this reason we have not recommended use of the HAProxy in cf-release for production environments.

This leaves the use case of development, or lab environments. Over the past year, we have begun thinking that the HAProxy provides no additional value here either. Since HA is not required in these environments, we have begun recommending<http://docs.cloudfoundry.org/adminguide/configure-lb-healthcheck.html> that operators point DNS directly at single instances of the CF Router and SSH Proxy.

Therefore, we're proposing deprecation of the HAProxy in cf-release. Of course, we want to hear your feedback. If you are currently leveraging the HAProxy in cf-release, please share your use cases.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

The CF CLI team just cut 6.23.1.
Deb, yum and Homebrew repos have been updated; binaries, installers and link to release notes are available at:

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


Reminder: 6.23.x is the last release to bundle the deprecated loggregator consumer library, which is used to talk to the loggregator endpoint on CF releases before v212.

In the next minor cf CLI release (6.24.0) this library is scheduled to be removed; regardless of the CF release version targeted, the noaa library will be used to talk to the doppler endpoint.
This endpoint was deemed stable around CF v203: if targeting an earlier CF release and experiencing issues with commands that interact with the loggregator (e.g. logs, push), please stay on a 6.23.x release of the cf CLI until your target CF is upgraded.

Request Ids in error messages

Where available, error messages from 5xx responses from API endpoints now include the request id, which can be helpful for platform operators to look up details on the interaction in CF's internal logs. (#998<https://github.com/cloudfoundry/cli/issues/998>)

License and copyright attributions

All binaries and installers now include up to date license and copyright attributions.

Fixed regressions

* delete-org immediately followed by a command/operation that depends on the deletion to have completed could fail in cf CLI 6.23.0 because delete-org returned without polling to wait for the deletion process to complete.

Updated commands

* push now continues with deployment even if the resource matching operation times out. (#1042<https://github.com/cloudfoundry/cli/issues/1042>)
* run-task now prints a tip in its help page how to inspect logs for a running task. (#1034<https://github.com/cloudfoundry/cli/issues/1034>)
* run-task now prints the (specified or generated) task name when it submits it.
* install-plugin no longer displays a localised (J oder N) with the confirmation prompt as it only responds to the English abbreviations. (As part of the refactor of all commands, all locales will eventually display a [yN] in confirmation prompts). (#994<https://github.com/cloudfoundry/cli/issues/994>)
* help now clarifies it displays only the most common, app developer focussed commands. (#1009<https://github.com/cloudfoundry/cli/issues/1009>)
* version now separates the build metadata (sha and build date) with a period (e.g. 6.23.0+3c307aa.2017-01-11) to make it easier to parse with SemVer libraries, and build the binary from source. (#992<https://github.com/cloudfoundry/cli/issues/992>, #1036<https://github.com/cloudfoundry/cli/issues/1036>)

New & updated community plugins

* get-events v0.6.0: https://github.com/ECSTeam/cf_get_events
* top v0.7.8: https://github.com/ECSTeam/cloudfoundry-top-plugin
* route-lookup v1.1.0: https://github.com/18F/cf-route-lookup<https://github.com/18F/cf-route-lookup>
* doctor v1.0.3: https://github.com/emirozer/cf-doctor-plugin

Enjoy!

Regards,
Dies Koper
Cloud Foundry Product Manager - CLI

Over that past year or two, CF teams have been extracting components from
cf-release into their own BOSH releases. This allows teams to innovate more
quickly. These releases are currently submoduled into cf-release, so that
cf-release can be used to deploy the full suite of core CF services. The
current plan is that cf-release will eventually be deprecated in favor of
cf-deployment <https://github.com/cloudfoundry/cf-deployment>, a toolchain
that generates a manifest for CF from these composable releases.

One of the last components in cf-release
<https://github.com/cloudfoundry/cf-release/tree/master/jobs> that has not
been extracted into its own release is HAProxy.

Historically, HAProxy has fulfilled two use cases: load balancing and TLS
termination. Since support for TLS termination was added to Gorouter, load
balancing may be the remaining use case.

In production environments, operators are expected to provide their own
redundant load balancers and configure them to forward requests to the CF
routers. HAProxy may provide a convenience where another load balancer is
not available, but as HAProxy is not inherently highly available in a
production environment it would require another load balancer in front of
it for HA, at which point HAProxy itself would be superfluous. For this
reason we have not recommended use of the HAProxy in cf-release for
production environments.

This leaves the use case of development, or lab environments. Over the past
year, we have begun thinking that the HAProxy provides no additional value
here either. Since HA is not required in these environments, we have begun
recommending
<http://docs.cloudfoundry.org/adminguide/configure-lb-healthcheck.html>
that operators point DNS directly at single instances of the CF Router and
SSH Proxy.

Therefore, we're proposing deprecation of the HAProxy in cf-release. Of
course, we want to hear your feedback. If you are currently leveraging the
HAProxy in cf-release, please share your use cases.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Hi,

Is there any progress on this one?

Regards,
Jacek

Hi Bernd,
What we do in these cases in Rakuten is to implement an API that receives requests from unprivileged users, perform any additional validation authorization logic we deem necessary and then, if authorization was granted, perform the operation with elevated privileges on behalf of the user.
Note that if you also implement a CLI plugin you don’t need to reimplement authentication, since you can instruct the plugin to forward the user token to your API, and then your API can query UAA to validate that the token is valid.

Carlo

Please disregard this email.





From: B Seguin <bs(a)starkandwayne.com>
Date: Wednesday, January 11, 2017 at 11:36 AM
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org>
Subject: Breakout Groups



Hello Team!



We are trying out something new by creating Breakout groups.

These groups have been created to maximize collaboration while reducing noise.

Not everyone in the company will be interested in or even needs to be involved in every group.

These groups represent company initiatives that would benefit from broader team input.

The goal is to enable people to get involved with things they care about and ignore things they don't care about or don't have time for, the choice is theirs.



The first two that we need help with are two that will help us get broader visibility and ultimately more clients outside of Pivotal:



1. CAB presentation of S&W projects



2. S&W Office Hours



For both of these we need volunteers to help kick off these efforts.



CAB presentation is someone talking about one of the S&W OSS projects to the community that shows up at the CAB call.

Office hours are designed for people to submit questions in advance and then they are answered live via Zoom with a designated speaker representative who is then backed up by the volunteers.

We are asking for everyone to volunteer to help once a month with office hours.

The complete list of breakout groups are listed on our wiki:



https://github.com/starkandwayne/wiki/wiki/Breakout-Groups

Please edit the wiki page and assign yourself to groups you are interested in.





B Seguin

Chief of Staff at Stark & Wayne

Phone: 716-359-7515

Email: bs(a)starkandwayne.com

Hello Team!



We are trying out something new by creating Breakout groups. 

These groups have been created to maximize collaboration while reducing noise. 

Not everyone in the company will be interested in or even needs to be involved in every group. 

These groups represent company initiatives that would benefit from broader team input. 

The goal is to enable people to get involved with things they care about and ignore things they don't care about or don't have time for, the choice is theirs.





The first two that we need help with are two that will help us get broader visibility and ultimately more clients outside of Pivotal:



1. CAB presentation of S&W projects



2. S&W Office Hours



For both of these we need volunteers to help kick off these efforts.



CAB presentation is someone talking about one of the S&W OSS projects to the community that shows up at the CAB call.

Office hours are designed for people to submit questions in advance and then they are answered live via Zoom with a designated speaker representative who is then backed up by the volunteers.

We are asking for everyone to volunteer to help once a month with office hours.



The complete list of breakout groups are listed on our wiki:



  https://github.com/starkandwayne/wiki/wiki/Breakout-Groups



Please edit the wiki page and assign yourself to groups you are interested in.





B Seguin

Chief of Staff at Stark & Wayne

Phone: 716-359-7515

Email: bs(a)starkandwayne.com

Hello all,

Pivotal is nominating Zach Robinson for the CAPI Project Lead in the
Runtime PMC.


Zach has worked as a core contributor to Cloud Foundry since 2013, most
recently as an engineer on CAPI. He has worked with the CF Services,
Runtime, and CAPI teams including anchoring Runtime and CAPI, with
contributions to most Cloud Foundry components. His previous experience
includes over 10 years of engineering, primarily in the financial sector.


Any other nominations should be sent to me/in reply by end of day January
17th, 2017.


If you have any questions about the role/process, please let me know.
These are described in the CFF governance documents. [1]

-Dieu Cao

Runtime PMC Lead

[1] https://www.cloudfoundry.org/wp-content/uploads/2015/09/CFF_
Development_Operations_Policy.pdf