Hello all,

Pivotal is nominating Abby Chau for the CF CLI Project Lead in the Application Runtime PMC.  She is currently serving as Interim Project Lead for the CLI team.

Abby Chau previously worked as a senior project manager and analyst for a higher education research firm in London where she eventually managed a team of analysts and product managers. She also spent time volunteering for Survival International, an indigenous rights organization. 

Abby moved to the Bay Area in 2014. She worked at various startups including DataFox as a Lead Data Analyst, and Moovweb as an Engagement Manager, where she worked with customers including GNC, CoverFX, Epson, and John Deere on mobile development. 

In a previous life, Abby worked at the Hawaii State Capitol as a legislative aide, and at the Hawaii International Film Festival. She joined Pivotal in October 2015 as a Technical Writer before making a transition to Product Manager in late 2016. 

Abby holds a BA in English Literature from the University of California, Berkeley and a MA from University College London. 

Any other nominations should be sent to me/in reply by end of day May 22nd, 2018.

-Dieu Cao

On Tue, May 15, 2018 at 3:28 PM, Dieu Cao <dcao@...> wrote:

Hello All,

This email is overly delayed and I apologize for that.

Jay Badenhope, the Project Lead for the cf CLI team within the Application Runtime PMC, transitioned to an internal project within Pivotal in late March. We thank him for his time serving as the CLI Project Lead.

The cf CLI team, primarily located in San Francisco, now has an opening for its project lead. Project leads must be nominated by a Cloud Foundry Foundation member.

Please send nominations to me/in reply to this posting by end of day May 22nd, 2018.

If you have any questions about the role/process, please let me know.

These are described in the CFF governance documents. [1]

-Dieu Cao

CF Application Runtime PMC Lead

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

Hi Matt,

We have tested this feature in Swisscom and it works great and as expected. 

Is there a timeline on your side to release this future finally?

Is there something we can further help you with testing or so?

Best regards,

Lukas

2018-03-27 16:05 GMT+02:00 Matt McNeeney <mmcneeney@...>:

I'm pleased to announce that the ability to share service instances across orgs and spaces has been released!

In order to use this feature, please make sure you are running:

• CF Deployment >= v1.9.0
• CF CLI >= v6.35.1

To share a service instance from one space into another, you just need to run cf share-service SERVICE-INSTANCE -s SPACE

Note that this needs to be enabled by both admins (via a feature-flag) and by the author of the service you want to share.

For more information, please check out the following docs:

• Sharing Service Instances (developers)
• Enabling Service Instance Sharing (service authors)

I'd encourage you all to try this out with a supportive service broker (like this example broker). This feature is currently experimental (beta), so feedback at this time would be extremely valuable.

Best wishes,

The CF Services API team

--

Freundliche Grüsse

 

Lukas Lehmann

 

Hello Team,

 

We are aware that cf release is no longer supported by community but we are using cf release in production environment. Migration to cf deployment is under progress.

We are using cf release v283 and routing release v163.When we upgrade routing from v163 to v164, we are getting error "Empty Reply from Server" when we curl the TCP application.

While upgrading routing release from v163 to v164, we have commented out "tcp_emitter" jobs, just kept the oauth_secret property for tcp_emitter inside routing manifest as mentioned in below specified link :

https://www.pivotaltracker.com/n/projects/1358110/stories/151400618

As mentioned in link "https://lists.cloudfoundry.org/g/cf-dev/attachment/7102/0/attachment.html",
also added following properties in CF manifest file :

tcp.enabled: true
routing_api.url: defaults to http://routing-api.service.cf.internal
routing_api.port: defaults to 3000
routing_api.auth_enabled: defaults to true

We also checked the logs inside tcp_router, found an error as "tcp-router.watcher.failed-to-get-next-routing-api-event".

Also checked the logs for routing_api which stats following errors:

Lost lock 'v1/locks/routing_api_lock'

Exit trace for group:\n lock-releaser exited with error: Exit trace for group:\n lock-maintainer exited with error: lock lost\n\nsql-route-pruner exited with nil\n metrics exited with nil\n route-register exited with nil\n conn-stopper exited with nil\n api-server exited with nil\n seed-router-groups exited with nil\n lock-acquirer exited with nil\n migration exited with nil\n.

Also set the log_level to debug for routing_api and tcp_router.

As tcp_emitter support has been removed from routing release version 164, so what configuration has to be done in place of it.

Please suggests configurations, modifications to be performed.

Thanks & Regards,

Kunal Bagwe

Atos Cloud Foundry

Atos

 

 

Hello all,

The CF Container Networking team has released cf-networking-release 2.0.0 and silk-release 2.0.0.

The releases do not contain major new features, but do include breaking changes for how the Cloud Foundry container networking system is packaged, versioned and deployed.

The biggest change is that the Silk container networking fabric, which may be swapped out for other CNI-compatible network integrations, is now provided in a dedicated BOSH release.  That leaves cf-networking-release with only those "core" components (Network Policy API and CNI compatibility layer) that serve as extension points for network integrations.  The split is intended to simplify the development and deployment of 3rd party network integrations in Cloud Foundry Application Runtime.

More detail

• To maintain existing container networking features in Cloud Foundry, operators will need to deploy both cf-networking-release and silk-release.  This is a breaking change for operators.

• We've "de-namespaced" many of the BOSH manifest properties and renamed some bosh jobs.  For manifest authors, these are breaking changes.

• Starting now and going forward, we plan to release both cf-networking-release and silk-release at the same time, with the same version numbers.  Operators using silk-release should plan to deploy both releases together; we won't support mixed-version deployments.

• We continue to provide upgrade guarantees from cf-networking-release 1.x to the 2.x versions.

• To deploy these releases with cf-deployment, we recommend using the use-cf-networking-2.yml experimental ops-file.  Longer term, we're intending for the 2.x versions to become default in cf-deployment.

For details, look at our release notes for cf-networking-release and silk-release.  If you have a non-standard BOSH manifest, be sure to read the cf-networking-release manifest changelog and silk-release manifest changelog.

As always, we welcome your questions and feedback in our Slack channel #container-networking or in reply to this message.

Try it out!

These new releases will be included by default in cf-deployment 2.0. Until then, you can use the opsfile cf-deployment/operations/experimental/use-cf-networking-2.yml

We have also duplicated and fixed other affected opsfiles, and suffixed them with ‘with-networking-2.yml’.

Best,

The CF Container Networking Team

[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