|
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@...>
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:
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!
[0] https://docs.google.com/document/d/1_OBnFCsL3ru43PEXocsCc3EuGaM0YLHjr0iAoXnakt4/edit?usp=sharing
|
|
|
|
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:
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! [0] https://docs.google.com/document/d/1_OBnFCsL3ru43PEXocsCc3EuGaM0YLHjr0iAoXnakt4/edit?usp=sharing |
|
|
|
FINAL REMINDER: CAB call for April is Wednesday 05/16 @ 8a PST or 11a EST
Michael Maximilien
FYI...
toggle quoted message
Show quoted text
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:
|
|
|
|
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/cl The README in routine-release v0.164.0 does mention at https://github.com/cloudfou Best, Eric, CF Diego PM On Mon, May 14, 2018 at 5:30 AM, Bagwe, Kunal <kunal.bagwe@...> wrote:
|
|
|
|
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:
|
|
|
|
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
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)
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
[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!
toggle quoted message
Show quoted text
On Thu, May 10, 2018 at 12:15 PM Shubha Anjur Tupil <sanjurtupil@...> wrote:
--
Chip Childers CTO, Cloud Foundry Foundation 1.267.250.0815 |
|
|
|
BookInfo app demo with Envoy as the edge router in CF
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/
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, |
|
|
|
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:
--
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 |
|
|
