Date   

Re: How to access CF services from external service in aws or k8s?

nilesh.subhash.salpe@...
 

FYI

 

-- 

 

 

From: "Salpe, Nilesh Subhash" <nilesh.subhash.salpe@...>
Date: Monday, 21 May 2018 at 10:42 AM
To: "cf-dev@..." <cf-dev@...>
Subject: How to access CF services from external service in aws or k8s?

 

Hi Guys ,

Can you please help me with questions?

 

https://stackoverflow.com/questions/50441278/how-to-access-cf-services-from-external-service-in-aws-or-k8s

 

 

Regards,

Nilesh

 


upcoming CFP deadlines

Swarna Podila
 

I just wanted to share a few upcoming deadlines for call for papers for events that might be relevant (and interesting) for y'all in our community to consider.  The list here is sorted in the order of deadline dates.

InnerSource Day is a gathering of industry practitioners discussing real-world implementations of this community-inspired, transformational approach to software development within the enterprise. A number of companies are adopting the practices of open source to create an internal company collaboration under the rubric InnerSource. Do you have a story to share about how you’ve implemented InnerSource in your organization? We want to hear about your successes and failures to build the community and practice of InnerSource.
Submission deadline: Friday, May 25
 
Istio Day at OSCON 
Istio is an open platform for connecting, managing, and securing microservices, providing an easy way to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, without requiring any changes in service code. So, if you know how to leverage Istio with open source tools such as Prometheus and Zipkin, have an Istio demo, or a great story or best practice to share, we want to hear from you.
Submission deadline: Tuesday, May 29 

DevOps Days Chicago
DevOpsDays Chicago brings development, operations, QA, InfoSec, management, and leadership together to discuss the culture and tools to make better organizations and products. The 2018 event will be the fifth time we have held DevOpsDays Chicago, and it should be bigger and better than ever before!
Submission deadline: Friday, June 1 (13:06 UTC)

Cloud Foundry Summit (Basel)
Well, obviously!! :-) 
Cloud Foundry Summit Europe is the premier event for end users to learn the platform from those who build and use it every day. Join hundreds of developers in Basel to learn how to run apps at scale – using a platform or containers on multiple clouds.
Submission deadline: Friday, June 1 (11.59pm US Pacific)
 
TensorFlow is a fast, flexible, and easy to use open-source machine learning library for research and production. The TensorFlow Community Day aims to bring together contributors and users to share experiences, increase collaboration, and advance the state of open source machine learning. We're looking for 30-minute talks from the community cross-platform use cases, related open source projects, using TensorFlow in the real world and more.
Submission deadline: Monday, June 4

Cheers,
Swarna. 


routing-release 0.178.0 released today

Shubha Anjur Tupil
 

Hi all, 

We cut routing-release 0.178.0 today downgrading Golang from 1.10 to 1.9. 

We found a breaking change in Golang 1.10 that the parsing of x509 certificates is much stricter.  Github issues on the regression here and here. Our plan is to upgrade to Golang 1.10 when a fix is released for this issue.

Side note: You might notice that there was no routing-release 0.177.0. The release is published but marked "Do Not Use" since it's a non-production ready release. We recommend skipping it. 

Regards, 
Routing team 


CF CLI v6.36.2 Released Today: Downgrades Golang to 1.9

Abby Chau
 

Hi all, the CF CLI team released v6.36.2 today:

Downgraded to Golang. 1.9

Due to a regression with certs in Golang 1.10, we've decided to publish a new release and downgrade our Golang version to 1.9.

This release is a tag of v6.36.1 with Golang version 1.9. When the issues have been fix in Golang, we will upgrade to 1.10.x.

Other Fixes


Let us know if you have any questions, thanks!

Best,

Abby Chau
CF Interim Product Manager - CLI


Re: CF Application Runtime PMC - CLI Project Lead Call for Nominations

Michael Maximilien
 

I second that nomination. 

I've worked with Abby and the CLI team recently and plan on working with them on and off as an engineer again this year.

I have nothing but good things to mention.

Best,

max

On Tue, May 15, 2018 at 3:29 PM, Dieu Cao <dcao@...> wrote:
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






Welcome MS SQL Broker and MultiApps to CF-Extensions

Michael Maximilien
 

FYI...

Brief announce to welcome MS SQL Broker [1] and MultiApps [2] to CF-Extensions. They were successfully voted in by members of the PMC. Congrats!

The respective initial teams from Microsoft and Pivotal (MS SQL) and SAP (MultiApps) will be working with the CFF (Chris C. and others) to move initial code to cloudfoundry-incubator org.

Feel free to ping team directly (see links below) or join the #cf-extensions slack channel for updates or best :) join our monthly calls [3].



Re: Feedback on service instance sharing (experimental)

Matt McNeeney
 

Hey Lukas,

Very pleased to hear the feature is working as you expected! As things stand, the feature should be released as GA within the next couple of months, and so far we haven't received any feedback that has made us rethink about how the feature works today.

Thanks,
Matt



On Wed, May 16, 2018 at 11:38 AM Lukas Lehmann <lukas92lehmann@...> wrote:
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:
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:

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
 


Re: Feedback on service instance sharing (experimental)

Lukas Lehmann
 

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:
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:

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
 


CF Application Runtime PMC - CLI Project Lead Call for Nominations

Dieu Cao <dcao@...>
 

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


Re: Improving Service Access in Cloud Foundry Application Runtime

Krannich, Bernd <bernd.krannich@...>
 

Hi Matt,

 

I was already tempted to ping you about the status of the topic. Seems like all the lobbying I did, both in writing [1] and in person is coming to a good end. 😉

 

I already left my feedback in the document and the suggested solution you outlined below looks good from my perspective.

 

Thanks so much, I believe users will like this quite a bit!

 

Regards,

Bernd

 

[1] https://github.com/cloudfoundry/cloud_controller_ng/issues/837

 

From: <cf-dev@...> on behalf of Matt McNeeney <mmcneeney@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Tuesday, 15. May 2018 at 10:15
To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev@...>
Subject: [cf-dev] Improving Service Access in Cloud Foundry Application Runtime

 

Hi all,

 

In Cloud Foundry Application Runtime, a Service Broker can only be registered once (either globally or space-scoped). This is because the Cloud Controller detects conflicts in the information exposed in a Service Broker's Catalog. However, we are aware of a number of use cases in which the same Service Broker should be registered multiple times in the platform, for example:

  • Development teams want to try out different Service Brokers for development (databases are commonly used) and register these as space-scoped. In multi-tenant environments, only the 'first' development team who tries to register a given Service Broker would succeed.
  • Different lines of business in a company want to register the same service broker (but using different credentials for billing purposes) into their Cloud Foundry orgs or spaces. These credentials are provided to the platform when a Service Broker is being created (or updated).

 

The CF Services API team would like to tackle this problem and have outlined a number of possible solutions in this proposal [0]. The solution we believe best solves this problem is allowing the name of a Service Broker to be used as an optional argument when multiple services with the same name are available in the marketplace. This would mean exposing the user-defined name of Service Brokers to all developers for the first time (we don't believe these to be confidential), and updating a number of CLI commands to display/consume this additional field.

 

For example, the marketplace would now should the name of a broker:

 

$ cf marketplace

service           plans         broker          description

service1          small         broker1         An example service

service1          small         broker2         An example service

 

And to create a new service instance using service1, the broker name would have to be provided:

 

$ cf create-service service1 small my-service

More than one service called ‘mysql’ is available. Please specify the name of the broker from which to provision this service with the ‘-b’ flag.

 

$ cf create-service service1 small my-service -b broker1

OK

 

 

We are looking for feedback on this proposal before we start this work, so please provide any feedback you have over the next week!

 

 

 

 

 


Deprecating Cloud Controller DELETE /v2/apps/:guid/service_bindings/:guid?

Luis Urraca
 

Hi All,

We are thinking about deprecating DELETE /v2/apps/:guid/service_bindings/:guid from the CC API. This endpoint is redundant as you can delete a service binding directly via DELETE /v2/service_bindings/:guid. We are also adding support for asynchronous service binding deletion and want new features to only exist in one place. Before marking this endpoint as deprecated we want to gather feedback from the community on who is using DELETE /v2/apps/:guid/service_bindings/:guid and whether switching to  DELETE /v2/service_bindings/:guid would be an issue. 

Thanks,

Services API (SAPI) Team
--
Luis Urraca


Improving Service Access in Cloud Foundry Application Runtime

Matt McNeeney
 

Hi all,

In Cloud Foundry Application Runtime, a Service Broker can only be registered once (either globally or space-scoped). This is because the Cloud Controller detects conflicts in the information exposed in a Service Broker's Catalog. However, we are aware of a number of use cases in which the same Service Broker should be registered multiple times in the platform, for example:
  • Development teams want to try out different Service Brokers for development (databases are commonly used) and register these as space-scoped. In multi-tenant environments, only the 'first' development team who tries to register a given Service Broker would succeed.
  • Different lines of business in a company want to register the same service broker (but using different credentials for billing purposes) into their Cloud Foundry orgs or spaces. These credentials are provided to the platform when a Service Broker is being created (or updated).

The CF Services API team would like to tackle this problem and have outlined a number of possible solutions in this proposal [0]. The solution we believe best solves this problem is allowing the name of a Service Broker to be used as an optional argument when multiple services with the same name are available in the marketplace. This would mean exposing the user-defined name of Service Brokers to all developers for the first time (we don't believe these to be confidential), and updating a number of CLI commands to display/consume this additional field.

For example, the marketplace would now should the name of a broker:

$ cf marketplace
service           plans         broker          description
service1          small         broker1         An example service
service1          small         broker2         An example service

And to create a new service instance using service1, the broker name would have to be provided:

$ cf create-service service1 small my-service
More than one service called ‘mysql’ is available. Please specify the name of the broker from which to provision this service with the ‘-b’ flag.

$ cf create-service service1 small my-service -b broker1
OK


We are looking for feedback on this proposal before we start this work, so please provide any feedback you have over the next week!






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

Michael Maximilien
 

FYI...

Please remember to join Wednesday morning for QAs, highlights, and three presentations:

1. Brief update on App Auto Scaler project by Bo Yang of IBM

2. Brief update on Service Fabrik by Ashish Jain of SAP

3. Presentation and live demo of BOSH Kube CPI by Dmitriy Kalinin of Pivotal and myself

Zoom soon. Best,

dr.max
ibm ☁ 
silicon valley, ca



dr.max
ibm ☁ 
silicon valley, ca


On May 10, 2018, at 4:07 PM, Michael Maximilien <maxim@...> wrote:

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: TCP Upgrade issue

Eric Malm <emalm@...>
 

Hi, Kunal,

Since you're still using a cf-release-based deployment manifest, I expect you also have a separate diego-release-based manifest to deploy the Diego cells and control-plane components, including the route-emitter. If that's correct, you should set the `tcp.enabled` BOSH property in your Diego manifest (for example, https://github.com/cloudfoundry/diego-release/blob/v1.31.0/manifest-generation/diego.yml#L264). This will configure the route-emitters (in either the cell-local or global modes) also to send TCP route registrations to the Routing API component, in addition to their original job of registering HTTP routes to the gorouters over the NATS message bus.

The README in routine-release v0.164.0 does mention at https://github.com/cloudfoundry/routing-release/tree/0.164.0#optional-redeploy-diego-to-enable-tcp-routes that this configuration is required to enable TCP route registrations and that you can enable it through the property-override input file to the spiff-based manifest generation script in diego-release.

Best,
Eric, CF Diego PM


On Mon, May 14, 2018 at 5:30 AM, Bagwe, Kunal <kunal.bagwe@...> wrote:
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 :
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
 
 



TCP Upgrade issue

Bagwe, Kunal <kunal.bagwe@...>
 

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 :
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
 
 


UAA on Compose for MySQL

Paul Bakare
 

Hi,

Caught something looking like a bug when UAA is faced with a clustered MySQL. Error details below:

2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT Migration V2_4_1__Zonify_Group_Memberships.sql failed

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT Statement  : UPDATE group_membership SET identity_zone_id = (SELECT identity_zone_id FROM users where users.id = group_membership.member_id)

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:555) ~[spring-beans-4.3.16.RELEASE.jar!/:4.3.16.RELEASE]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.springframework.beans.factory.support.AbstractBeanFactory$1.getObject(AbstractBeanFactory.java:312) ~[spring-beans-4.3.16.RELEASE.jar!/:4.3.16.RELEASE]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:308) ~[spring-beans-4.3.16.RELEASE.jar!/:4.3.16.RELEASE]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:197) ~[spring-beans-4.3.16.RELEASE.jar!/:4.3.16.RELEASE]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     ... 49 common frames omitted

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT Statement  : UPDATE group_membership SET identity_zone_id = (SELECT identity_zone_id FROM users where users.id = group_membership.member_id)

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.flywaydb.core.internal.command.DbMigrate.access$800(DbMigrate.java:53) ~[flyway-core-4.2.0.jar!/:na]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.flywaydb.core.internal.metadatatable.MetaDataTableImpl.lock(MetaDataTableImpl.java:174) ~[flyway-core-4.2.0.jar!/:na]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.flywaydb.core.internal.command.DbMigrate.migrate(DbMigrate.java:146) ~[flyway-core-4.2.0.jar!/:na]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.flywaydb.core.Flyway$1.execute(Flyway.java:1010) ~[flyway-core-4.2.0.jar!/:na]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.flywaydb.core.Flyway$1.execute(Flyway.java:971) ~[flyway-core-4.2.0.jar!/:na]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.flywaydb.core.Flyway.execute(Flyway.java:1464) ~[flyway-core-4.2.0.jar!/:na]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_172]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_172]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_172]

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT Caused by: java.sql.SQLException: (conn:32607) The table does not comply with the requirements by an external plugin.

   2018-05-11T22:06:17.47+0100 [APP/PROC/WEB/0] OUT     at org.mariadb.jdbc.internal.util.ExceptionMapper.throwAndLogException(ExceptionMapper.java:77) ~[mariadb-java-client-1.5.9.jar!/:na]



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


Re: CF Container Networking 2.0!

Shannon Coen
 

Kudos to the Networking team!

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, May 11, 2018 at 11:11 AM, Amelia Downs <adowns@...> wrote:

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





CF Container Networking 2.0!

Amelia Downs
 

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




Voting is open! (Re: Summit EU: CFP and Co-Chair Nominations)

Swarna Podila
 

Love the number of nominations we received for the track co-chairs!  Great job, everyone.

Please look at the nominations for each track and cast your vote today!  The deadline to submit your vote is May 15th 11.59pm US pacific time.

If you have any questions, unicast me here or ping me on slack.

Thank you,
Swarna.


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 


1381 - 1400 of 9389