Date   

CAB call for April is Wednesday 05/16 @ 8a PST or 11a EST

Michael Maximilien
 

FYI...

 

Reminder that the CAB call for May is scheduled for next Wednesday 05/16 @ 8a PST / 11a EST. Zoom Details here [1].

 

I have spot for one more presentation. Please contact me directly here or via slack so I can consider.


I’ll send one more reminder with details early next week.

 

Best,

 

------

dr.max

ibm  

silicon valley, ca

maximilien.org

 

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



Re: BookInfo app demo with Envoy as the edge router in CF

Chip Childers <cchilders@...>
 

Outstanding progress. This is really great to see Shubha and team!

On Thu, May 10, 2018 at 12:15 PM Shubha Anjur Tupil <sanjurtupil@...> wrote:

[Edited Message Follows]

Hello all, 
 
The routing team has been working on integrating Envoy and Istio in the routing control plane. Yesterday we were able to run the BookInfo demo with Envoy as the edge router ( still using DNS load balancing for E-W traffic). See the attached GIF for a micro-demo and see the requests load balanced between the three versions of the reviews app (the black stars, red stars, and no stars with a written review). 
 
While this is test-driven and CI'd functionality, we want to clarify that istio-release is considered experimental/alpha.
 
For more on our initiative to leverage Istio and Envoy, see https://docs.google.com/document/d/1LgLY0g39fzpg1_4zTckbH1mOuuSKGvYwp2tkakoe9ys/edit
 
​​
Routing team

--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


BookInfo app demo with Envoy as the edge router in CF

Shubha Anjur Tupil
 
Edited

Hello all, 
 
The routing team has been working on integrating Envoy and Istio in the routing control plane. Yesterday we were able to run the BookInfo demo with Envoy as the edge router ( still using DNS load balancing for E-W traffic). See the attached GIF for a micro-demo and see the requests load balanced between the three versions of the reviews app (the black stars, red stars, and no stars with a written review). 
 
While this is test-driven and CI'd functionality, we want to clarify that istio-release is considered experimental/alpha.
 
For more on our initiative to leverage Istio and Envoy, see https://docs.google.com/document/d/1LgLY0g39fzpg1_4zTckbH1mOuuSKGvYwp2tkakoe9ys/edit
 
​​
Routing team


Re: How to check validity of access token in UAA? #cf

Tian Wang
 

Hi Shilpa,

The introspection endpoint was added in UAA 4.9.0. From your Postman, it shows your UAA version is 4.3.0. If you check out the latest UAA, you should see the endpoint work. Prior to 4.9.0, UAA has the check_token endpoint but it does not include the active flag, and returns 4XX errors for invalid tokens.

Regards,

Tian

On Tue, May 8, 2018 at 4:08 AM, shilpa kulkarni <shilpakulkarni91@...> wrote:
Hello,

I am using cloud foundry UAA APIs.  I want to check whether the access token has expired or not . In the API documentation,  I am getting Introspect token API[Active flag is responsible for showing the validity of the token].
Reference link:
http://docs.cloudfoundry.org/api/uaa/version/4.12.0/#introspect-token

But while testing this Introspect token API in postman, I am getting 404 Not found error. Following is my test documentation:
https://documenter.getpostman.com/view/1991110/introspect-token/RW1gFHma

How to check validity of access token? 

Thanks & Regards
Shilpa Kulkarni



NOTICE: [python-buildpack] End of Python 3.3.x support after 2018-06-08

Scott Sisil
 

Support for Python 3.3.x will be removed in the first release of the Python buildpack after 2018-06-08.


Per Python Development policy, all support for the 3.3 series of releases ended on 2017-09-29, five years after the initial release[1]. We are giving users a 30 day notice before support for Python 3.3.x is officially removed from the Python buildpack. Because 3.3.x has long been in security-fix mode, 3.3.7 may no longer build correctly on all current operating system releases and some tests may fail.  If you are still using Python 3.3.x, we strongly encourage you to upgrade to a more recent, fully supported version of Python 3.


[1] https://www.python.org/downloads/release/python-337/




Scott


CF Buildpacks PM




How to check validity of access token in UAA? #cf

shilpa kulkarni
 

Hello,

I am using cloud foundry UAA APIs.  I want to check whether the access token has expired or not . In the API documentation,  I am getting Introspect token API[Active flag is responsible for showing the validity of the token].
Reference link:
http://docs.cloudfoundry.org/api/uaa/version/4.12.0/#introspect-token

But while testing this Introspect token API in postman, I am getting 404 Not found error. Following is my test documentation:
https://documenter.getpostman.com/view/1991110/introspect-token/RW1gFHma

How to check validity of access token? 

Thanks & Regards
Shilpa Kulkarni


Re: Proposed BOSH logging interface

Marco Voelz
 

Dear Jesse,


Thanks for putting this proposal out there. We would be happy to see an automated logfile forwarding mechanism. Here's a couple of comments on your initial points:

* Including the filename in the syslog metadata is very useful and something we'd really like to have. Currently it is something we're working around a bit.

* The appname/tag field should probably contain the release's name as well as a prefix. My proposal here is `<deployment name>.<instance group name>.<job name>`. wdyt?

* We haven't made any particular use of the priority field, so losing control over this field wouldn't matter for out use-cases. Severity is usually something that the actual log message needs to contain, as the logger's severity can only be set on its initial creation, afaik.

* Restricting the depth of recursion seems reasonable. So far, I don't think we're using bosh releases which have more than 1 folder below their /var/vcap/sys/log/<job name>/ folder.


Concerning the requirements about permissions on the logfiles you'd want to forward: Did you talk to Dmitriy/the BOSH team about this? With stemcell series 3541.x the permissions on the standard folders below /var/vcap were tightened a bit, so just wanted to make sure that your assumptions are in line with the upcoming changes in the stemcells.


Warm regards

Marco


From: cf-dev@... <cf-dev@...> on behalf of Jesse T. Alford <jalford@...>
Sent: Tuesday, April 3, 2018 12:55:38 AM
To: cf-dev@...
Subject: [cf-dev] Proposed BOSH logging interface
 
Hello! We're the CF Platform Logging team. We maintain `syslog-release` and have been working to improve and regularize platform logging behavior.

This is a proposal intended to establish reasonable expectations about what should be logged and what should be forwarded in bosh-deployed cloud systems.

Historically, it has been up to each release to provide for their log forwarding, if any. We intend `syslog-release` to provide a consistent interface useful enough to replace all other provisions for the forwarding of logs from bosh jobs.

## Proposed Interface
If log forwarding is enabled, some files in `/var/vcap/sys/log` (and its subdirectories, recursively), will have any line written to them forwarded as the MSG portion of an RFC5424 compliant syslog message. Which files are forwarded is governed first by file extension, and secondarily by file permissions.

`syslog-release` attempts to read any file ending in `.log`.
(This allows us to avoid forwarding rotated logs, swapfiles, etc.)
It will forward from such files if either of the following are true:
- it is world-readable
- it is readable to the `vcap` group

In particular, this means that logs will not be forwarded from files where:
- user and group are root:root
- user and group are vcap:root or vcap:none
- user and group are vcap:vcap, but it is not group-readable

…unless they are world-readable.

We think that this interface will allow us to avoid running a log forwarder with elevated permissions, while also allowing jobs to, for instance, write DEBUG or similar logs to a file that is not group-readable, thus improving their security and reducing the load on the logging system while still making them available on the ephemeral disk for debugging purposes.

## Questions
There are a couple of things around this interface we're especially interested in feedback on, in addition to the obvious "will this be a problem for you" overall question.

We may have to have a proviso that the depth of this is not unlimited. This depends somewhat on what is inexpensive to implement and maintain, and is an area we'd appreciate feedback on. Is three levels deep from `/var/vcap/sys/log` (i.e. `/var/vcap/sys/log/jobname/processname/*`) enough? Would four be?

In the old way of doing things, more control over the PRI information and other syslog fields was available to release authors. Logs forwarded from files currently all come out as PRI 14, which translates to Facility: User, Severity: Info. Additionally, the appname/tag field is set to the name of the directory containing the log file. Is this enough/good info? If we were to include the filename, too, would that be useful? Sufficient?

## Testing with the Proposed Interface
We have recently implemented a feature to help release authors evaluate the proposed interface. If you set `syslog.respect_file_permissions: true`, blackbox will not be run with elevated capabilities, and you'll be able to see what is and isn't forwarded under the proposed interface.


Re: Equivalent API to adding member to a group

Paul Bakare
 

Nevermind. UAA /Groups does it.

On Mon, May 7, 2018 at 11:09 PM, Paul Bakare <dreyemi@...> wrote:
Hi,

What's the equivalent UAA API to:

uaac member add custom.report xyz@...

--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde




--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde


Equivalent API to adding member to a group

Paul Bakare
 

Hi,

What's the equivalent UAA API to:

uaac member add custom.report xyz@...

--
Odeyemi 'Kayode O.
http://ng.linkedin.com/in/kayodeodeyemi. t: @charyorde


NOTICE : [ruby-buildpack] End of Node.js 4.x support after 2018-06-07

Scott Sisil <ssisil@...>
 

Support for Node.js 4.x will be removed in the first release of the Ruby buildpack after 2018-06-07.


The Node.js Release Working Group ended support for Node.js 4.x on 2018-04-30 [1][2]. We are giving users a 30 day notice before support for Node.js 4.x is officially removed from the Ruby buildpack.  We recommend migrating any applications using release 4.x to LTS release 6.x.


Scott Sisil


CF Buildpacks PM


[1] https://github.com/nodejs/Release

[2] https://medium.com/the-node-js-collection/april-2018-release-updates-from-the-node-js-project-71687e1f7742


Re: Call for Demos - CF / K8S Integration SIG Meeting

Chip Childers <cchilders@...>
 

Also: for Wednesday I forgot that Dobromir also was preparing to demo the service manager project!

On Sun, May 6, 2018 at 6:56 PM Chip Childers <cchilders@...> wrote:
Outstanding response to this request folks!

For this Wednesday, I'd like to ask for:

(1) Sree to demonstrate UAA + k8s
(2) Julz to demonstrate Erini

Along with both of those, we should do a round up of updates from anyone working in related areas / projects.

I'll work with the other proposals to find a good slot in the coming meetings. I have proposals from Jeenal, Dr Max, Adam H and Ashish. Should if I missed an email or you want to be on the list too!

-chip


On Thu, Apr 26, 2018 at 5:53 PM Chip Childers <cchilders@...> wrote:
During yesterday's CF/K8S SIG meeting, several speakers proposed demo'ing their various efforts during a future call.

I'd like to formally request replies from anyone interested in giving a demo, and we'll work out an agenda for the next (and future) SIG calls based on responses.

So far, I have an offer from SAP for Dobromir Zahariev to demo the work around service catalog sync between CFAR and K8S.

Anyone else willing?

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Call for Demos - CF / K8S Integration SIG Meeting

Chip Childers <cchilders@...>
 

Outstanding response to this request folks!

For this Wednesday, I'd like to ask for:

(1) Sree to demonstrate UAA + k8s
(2) Julz to demonstrate Erini

Along with both of those, we should do a round up of updates from anyone working in related areas / projects.

I'll work with the other proposals to find a good slot in the coming meetings. I have proposals from Jeenal, Dr Max, Adam H and Ashish. Should if I missed an email or you want to be on the list too!

-chip

On Thu, Apr 26, 2018 at 5:53 PM Chip Childers <cchilders@...> wrote:
During yesterday's CF/K8S SIG meeting, several speakers proposed demo'ing their various efforts during a future call.

I'd like to formally request replies from anyone interested in giving a demo, and we'll work out an agenda for the next (and future) SIG calls based on responses.

So far, I have an offer from SAP for Dobromir Zahariev to demo the work around service catalog sync between CFAR and K8S.

Anyone else willing?

-chip
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: How can we customized "404 Not Found"

David McClure
 

Nice! Love the gif demo :)

On Wed, May 2, 2018 at 6:32 PM, Shannon Coen <scoen@...> wrote:

[Edited Message Follows]

Today the CF Routing team added the ability for an Envoy proxy deployed as the edge router for CF (using istio-release) to return a 503 instead of a 404 for a requested route when the mapped app is stopped or crashing. 

We are thrilled as this represents the first new routing feature in Cloud Foundry enabled by our next-gen routing subsystem based on Istio and Envoy. See the attached GIF for a micro-demo. 

While this is test-driven and CI'd functionality, I want to clarify that istio-release is considered experimental/alpha. 

For more on our initiative to leverage Istio and Envoy, see https://docs.google.com/document/d/1LgLY0g39fzpg1_4zTckbH1mOuuSKGvYwp2tkakoe9ys/edit



CF routing-release 0.176.0

Shubha Anjur Tupil
 

Hi all,

We just released routing release 0.176.0 with features to enable compliance with the EU General Data Protection Regulation (GDPR).


- Operators can now configure a manifest property `router.disable_log_forwarded_for` to disable logging of X-Forwarded-For header in Gorouter logs. This is to comply with EU regulations that do not allow persisting personal data. Details here

- Operators can now configure a manifest property `router.disable_log_source_ip` to disable logging of source IP in Gorouter logs. This is to comply with EU regulations that do not allow persisting personal data. Details here

- We fixed an issue where Gorouter was not previously forwarding/settings the client certificate in the XFCC header when a request was being proxied through a route service. Gorouter now sets the XFCC header with the client certificate. See the manifest property `router.forwarded_client_cert` to understand the options available for forwarding a client certificate. Details here


Please let us know if you have any feedback and/or questions. Happy to help!


Regards, 

Shubha & Shannon 

Routing PMs




CF CLI Minimum Supported Version

Abby Chau
 

In order to focus our resources on the most valuable features and bug fixes, the CF CLI team periodically announces the end of support for older Cloud Controller (CC) API versions. The current CF CLI is backwards compatible to CF 203 / CC API 1.23, from March 2015.


Going forward, we want to give users a more predictable annual cycle for cf CLI version support cut-offs so you can plan accordingly. We also want to tighten up this timeline so the CF CLI team can narrow its focus to fewer CC API versions without unduly disrupting your use of CF.


To this end, moving forward, CF CLI will only maintain support as far back as the previous year’s CF Certification, and we've also add additional cushion to enable a more seamless upgrade process. Older CF CLI versions compatible with older CF releases will continue to be available. However, upon the new year, the first CLI release of that year will remove all code pertaining to unsupported releases.


Starting in 2018, CF CLI will only support:

  • Previous Year’s CF Certification: CF Certification 2017

  • CF Release in January 2017: v251 (CAPI Release: 1.15.0 (APIs 2.69.0 and 3.4.0)


Starting in 2019, CF CLI will only support:

  • Previous Year’s CF Certification: CF Certification 2018

  • CF-Deployment Release in January 2018: v1.7.0. (CF Release in January 2018: v284)

  • CAPI Release on January 1st, 2018: 1.46.0 (APIs 2.100.0 and 3.35.0)


The CF CLI team welcomes any feedback you may have regarding this. We can be reached via this email, or on Slack at #cli. Thanks!


Best,


CF CLI team



Wanted: Cloud Foundry Blog Content

Caitlyn O'Connell <coconnell@...>
 

Hi all:

As we unwind after a highly successful Summit, we've been thinking about the type of content we'd like to feature on the Cloud Foundry blog. We have a dearth of Tutorial/How-to content, and we'd like to remedy that.

If you have an awesome, Cloud Foundry-adjacent how-to that you'd like to turn into a tutorial blog, please get in touch with me. And here's a quick reminder on blog publishing protocol:


How to Publish on the Cloud Foundry Blog


Step 1: Draft your post in a Google Doc and share it with Caitlyn, who will make edits/comments.

Step 2: Login to the Cloud Foundry blog with your username and password at https://www.cloudfoundry.org/wp-login.php

Step 3: Draft approved copy and save draft

Step 4: Share any images for the post with Caitlyn via email

Step 5: Caitlyn will make SEO tweaks including categories and keywords, then will schedule the post to go out

Step 6: Cloud Foundry will share the post on social -- and you should too!



Thank you, and please get in touch with content/questions!

Best,
Caitlyn

--
Caitlyn O'Connell
Marketing Communications Manager
Cloud Foundry Foundation
818 439 5079 | @caitlyncaleah

Want to contribute to our blog? Email content@...

Interested in how you can try out Cloud Foundry? Read about 2018 certified platforms.


NOTICE : [nodejs-buildpack] End of Node.js 4.x support after 2018-06-04

Scott Sisil <ssisil@...>
 

Support for Node.js 4.x will be removed in the first release of the Node.js buildpack after 2018-06-04.


The Node.js Release Working Group ended support for Node.js 4.x on 2018-04-30 [1][2]. We are giving users a 30 day notice before support for Node.js 4.x is officially removed from the Node.js buildpack.  We recommend migrating any applications using release 4.x to LTS releases 6.x, 8.x or 10.x.


Thanks,


Re: How can we customized "404 Not Found"

Shannon Coen
 
Edited

Today the CF Routing team added the ability for an Envoy proxy deployed as the edge router for CF (using istio-release) to return a 503 instead of a 404 for a requested route when the mapped app is stopped or crashing. 

We are thrilled as this represents the first new routing feature in Cloud Foundry enabled by our next-gen routing subsystem based on Istio and Envoy. See the attached GIF for a micro-demo. 

While this is test-driven and CI'd functionality, I want to clarify that istio-release is considered experimental/alpha. 

For more on our initiative to leverage Istio and Envoy, see https://docs.google.com/document/d/1LgLY0g39fzpg1_4zTckbH1mOuuSKGvYwp2tkakoe9ys/edit


CF CLI/GoLang Dropping Support for Legacy Operating Systems #cf

Anand Gaitonde
 

The GoLang release (1.10) made the following announcement:


Go 1.10 is the last release that will run on OpenBSD 6.0. Go 1.11 will require OpenBSD 6.2.

Go 1.10 is the last release that will run on OS X 10.8 Mountain Lion or OS X 10.9 Mavericks. Go 1.11 will require OS X 10.10 Yosemite or later.

Go 1.10 is the last release that will run on Windows XP or Windows Vista. Go 1.11 will require Windows 7 or later.


While this requires no immediate action for anyone, we would like the users of the CF CLI to be aware that once the CF CLI upgrades to GoLang 1.11, it will no longer support operating systems that GoLang does not support.


Following the GoLang release schedule, Go 1.11 will be released around August 2018, giving affected customers at least six more months to upgrade to a supported version.


If you feel like the CF CLI Team should refrain from upgrading to GoLang 1.11 upon its release, please voice your concerns now and we will adjust our upgrade cycle accordingly.


Additional notes:

  • According to our downloads stats of the last year, Windows makes up 5.54% and OS X makes up 1.98% of totals downloads.

  • Approximately 0.1% of total CF CLI downloads over the last year are made by the affected systems. The overwhelming majority of said downloads are Windows XP.

  • Microsoft dropped support of Windows XP on April 8, 2014.

  • Microsoft dropped support of Vista on April 11, 2017.

  • According to the Apple Security Updates page, the last time Mavericks (10.9) was updated was in March 2017. It has not gotten any security fixes since then.


Announcing BOSH Kube CPI

Michael Maximilien
 

fyi...

As the cool kids do it these days, see:


The gist are in these links:


PDF of presentation: https://bit.ly/bosh-kube-cpi

We'd love to hear your feedback.

Best,

Dmitriy and Max

1421 - 1440 of 9410