Shannon,

Can you share about the improvements you are talking about ?

Thanks

2017-01-19 9:46 GMT+09:00 Shannon Coen <scoen(a)pivotal.io>:

The Routing team is moving from cloudfoundry/lager to uber-go/zap logging
library for the Gorouter log, as we have observed improvements to
throughput performance using zap. This change has no impact on the
access.log, only to gorouter.log.

The Gorouter log message will change in the following ways. Please let us
know if any of these are a concern. Thank you!

1. "session" removed from "data" key. Does anyone use this?

lager
"data":{"host":"10.0.32.21:4222","session":"1"}

zap
"data":{"host":"10.0.32.21:4222"}


2. Values for "source" key more granular. Seems helpful for filtering
messages for like operations

lager
"source":"vcap.gorouter"

zap
"source":"vcap.gorouter"
"source":"vcap.gorouter.nats"
"source":"vcap.gorouter.subscriber"
"source":"vcap.gorouter.router"
"source":"vcap.gorouter.registry"


3. Source no longer prepends value of "message" key, as it is redundant to
the "source" key.

lager
"message":"vcap.gorouter.starting"

zap
"message":"starting"

4. Key reordering. My expectation is that no one should be using key order
for log analysis.

lager
{"timestamp","source","message","log_level","data"}

zap
{"log_level","timestamp","message","source","data"}


Full example log messages:
https://gist.github.com/shalako/79c8d7e8bf6d26b9934bb2679914c856

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

Hi all!

On today's CAB call, Dr. Max asked if this thread could be bumped so
everyone is reminded to see it.

Contributors: Don't forget to register!

-chip

On Wed, Nov 30, 2016 at 12:22 PM Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

Hi all!

Some of you may have noticed that the registration is now open for the
upcoming CF Summit in Silicon Valley, and we are offering free passes for
contributors to the project again.

This code can be used by anyone that is a contributor to a Cloud Foundry
or BOSH project. We consider contributions to be project leads, dedicated
committers or even if you have sent in a pull request to one of the
projects.

Use of the code is on the honor system... ;-)


https://www.cloudfoundry.org/summit2017/?utm_source=flash&utm_campaign=summit_2017_sv&utm_medium=eml&utm_term=cloud%20foundry%20summit


Code: CFSV17CONT
Feel free to reach out to me or to events(a)cloudfoundry.org if you have
any questions.

See you there!
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815

Hello - we originally thought we were not vulnerable to a vulnerability in
RunC but turns out it is complicated. Please see updated notice below.

https://www.cloudfoundry.org/cve-2016-9962/

Please let me know if you have any questions.

Thanks,
Molly Crowther
CFF Security Team

RunC Exec Vulnerability

Severity

Medium/Low
Vendor

Open Containers Initiative
Description

RunC allowed additional container processes via runc exec to be ptraced by
the pid 1 of the container. This allows the main processes of the
container, if running as root, to gain access to file-descriptors of these
new processes during the initialization and can lead to container escapes
or modification of runC state before the process is fully placed inside the
container.
Affected Cloud Foundry Products and Versions

- Garden-runC versions prior to 1.1.1

The Cloud Foundry team has determined that the project is not exposed to
this particular vulnerability and therefore does not require any upgrades.
As Cloud Foundry never runs user processes as pid 1 and runs all buildpack
containers as unprivileged users in a user namespace, and as Cloud Foundry
uses apparmor to prevent ptrace, the specific exploit in the CVE is not
possible.

However, the CVE patch from runC also worked around an Ubuntu kernel bug
that resulted in file descriptors which were inherited by a new process
being available for a very short time when they should have been
automatically closed. This could result in a container being able to access
files on the host, although not with elevated permissions.
Mitigation

OSS users are encouraged to follow one of the mitigations below:

- Upgrade garden-runC to version 1.1.1 or later.

Credit

Credit for this discovery goes to Aleksa Sarai from SUSE and Tõnis Tiigi
from Docker.
References

- Original CVE from Docker: http://seclists.org/oss-sec/2017/q1/54
- Ubuntu tracking for kernel bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1654602

Hi all,

In service of the initiative to remove the hard dependency on Consul for Locks
& Service Discovery in CF Runtime
<https://docs.google.com/document/d/16O5Rk5tOmHc2Qeya7soVHoASAgrH9jYZ0V3fS58dY14/edit>,
we are proposing BOSH-native DNS in the form of a BOSH-aware DNS server.
Please see the proposal document
<https://docs.google.com/document/d/1GsS1S7XFJoeLR1kYY46u4pcX08lRDvXUrjkssuyKI4s/edit#>
for more details and discussion.

Regards,
Amit

I like the direction. This change will be good.

Mike

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