|
Re: Diego as Default?
Leandro David Cacciagioni
Thanks a lot!!!
toggle quoted message
Show quoted text
2017-02-03 19:06 GMT+01:00 David Sabeti <dsabeti(a)pivotal.io>: Hi Leandro, |
|
|
|
Re: Diego as Default?
David Sabeti
Hi Leandro,
toggle quoted message
Show quoted text
I've been holding off on defaulting to the Diego backend primarily because we planned to make that change when we shipped cf-deployment <https://github.com/cloudfoundry/cf-deployment>. That repo is still under development and won't be ready for a little while longer, so I think it makes sense to go ahead and update the spiff templates in cf-release to use Diego by default. I've written a Pivotal Tracker story that you can keep an eye on here <https://www.pivotaltracker.com/story/show/139030003>. It likely won't make it into CF 252, but we'll definitely have it by CF 253. In the meantime, you can still use the `generate_deployment_manifest` script in cf-release and use Diego; all you need to do to enable Diego is override this property <https://github.com/cloudfoundry/cf-release/blob/master/templates/cf.yml#L805> by setting the value in your spiff stub. It would look something like this: properties: ... cc: default_to_diego_backend: true Feel free to reach out if you need any other help deploying. David Sabeti Product Manager, CF Release Integration On Fri, Feb 3, 2017 at 1:52 AM Leandro David Cacciagioni <
leandro.21.2008(a)gmail.com> wrote: guys is there any reason why Diego is not enabled by default in the `generate_deployment_manifest` templates? AFAIK DEA arch is being deprecated in a few months so I think it could be good to already have it as default. Then since Diego is not in the defaults which guide did I follow for AWS diego deployment the ones in Diego docs( https://github.com/cloudfoundry/diego-release/tree/develop/examples/aws), the ones in the cf-release ( https://github.com/cloudfoundry/cf-release/tree/master/example_manifests) or which ones? Thanks, Leandro.- |
|
|
|
Diego as Default?
Leandro David Cacciagioni
guys is there any reason why Diego is not enabled by default in the
`generate_deployment_manifest` templates? AFAIK DEA arch is being deprecated in a few months so I think it could be good to already have it as default. Then since Diego is not in the defaults which guide did I follow for AWS diego deployment the ones in Diego docs( https://github.com/cloudfoundry/diego-release/tree/develop/examples/aws), the ones in the cf-release ( https://github.com/cloudfoundry/cf-release/tree/master/example_manifests) or which ones? Thanks, Leandro.- |
|
|
|
Asynchronous route-mapping and blue-green deployment
Anderer, Thomas
Hello everyone,
we already had an internal discussion on the topic and since we could not quite come to a solution, I'd like to ask in this list. We're using a self-made blue-green-deployment-script which pretty much does what's explained on cloudfoundry.org (https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html), and additionally checks (HTTP-GET) the application after push, map-route and unmap-route. This script has been working fine on an instance A of CF (DEA-based and relatively small), but has issues on instance B (Diego-based, larger). The aforementioned HTTP-GET sometimes fails with "404 Not Found: Requested route does not exist" directly after push or map-route. We never experienced this issue on instance A. This could of course mean that the instance is small enough that all router operation are handled faster than our script is able to react. On instance B it sometimes takes up to a 1 second or even longer until the route mapping is finally completed. In our internal discussion with our CF operators, we found a couple of parts of documentation which at least hint to different, maybe even inconsistent inner workings of the route mapping: 1) https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html: Step 3: Map-route - The CF Router immediately begins to load balance traffic for demo-time.example.com between Blue and Green. - In my opinion this implies or at least strongly hints that the map-route call was supposed to be synchronous. 2) PUT to "/v2/apps/#{app_guid}/routes/#{route_guid}" returns 201 CREATED and not 202 ACCEPTED, which also implies that it is a synchronous operation. It also does not return an event or operation which could be pinged to wait for completion of route mapping. 3) Operations which show the state of the route, like for example 'cf routes' already shows the route as being successfully mapped, although 404 is still returned. 4) See https://docs.cloudfoundry.org/devguide/deploy-apps/routes-domains.html#map-route: Applications running on the DEA architecture must be restarted after routes for an app are mapped or unmapped. Applications running on Diego do not need to be restarted. - This is contrary to what I experienced, since route mapping on our instance A always worked synchronously and without restart of the application. Furthermore, it contradicts what's explained in 1) at least for DEA. 5) https://github.com/cloudfoundry/diego-design-notes#routing-translation-components: Routing Translation Components: Route-Emitter a) monitors DesiredLRP state and ActualLRP state via the BBS. When a change is detected, the Route-Emitter emits route registration and unregistration messages to the gorouter via the NATS message bus, b) periodically emits the entire routing table to the router, c) maintains a lock in consul to ensure only one route-emitter handles route registration at a time. - This hints that route mapping is an asynchronous task. Some of the issues could be fixed by repeatedly pinging the application in order to wait until the route has been mapped. But what about blue-green-deployment, where I map the application to a route on which there is already a running application. Here, I cannot find out in a general way, if the route mapping is completed and when I can start unmapping the route from the old application. If route-mapping is indeed an asynchronous task, in my opinion the description on https://docs.cloudfoundry.org/devguide/deploy-apps/blue-green.html is misleading at best. And all blue-green-deployment-scripts which I've seen so far have this issue. So, is the route mapping really supposed to be asynchronous? If so, is there any general way to find out when the route-mapping process has finished? Thank you for your help and clarification, Best regards, -- Thomas Anderer Agile Software Engineer andrena objects ag currently working at SAP |
|
|
|
UAA 3.10.0 Release Announcement
Sree Tummidi
Hi All,
On behalf of the entire UAA team I am pleased to announce the release of *UAA 3.10.0*. This release truly has been community driven effort with major feature contributions from *SAP* and *Microsoft*. The release highlights include Major FeaturesExternal User Claims via UserInfo Endpoint This feature enables User Attributes (including custom attributes) and Group Memberships from LDAP, SAML and OpenID Connect providers to be exposed via the UserInfo endpoint of UAA in addition to propagating them via OpenID Connect id_token. This is an optional feature per external identity provider and is turned on by setting the config.storeCustomAttributes flag in the Identity Provider json. The token must contain user_attributes and/or roles scopes for retrieving the custom attributes and roles from the /userinfo <http://docs.cloudfoundry.org/api/uaa/#user-info> endpoint. - Ability to retrieve the custom user attributes from the OpenID Connect userinfo endpoint External OIDC <https://www.pivotaltracker.com/story/show/130477291> - Ability to retrieve the roles from the OpenID Connect userinfo endpoint - All Providers <https://www.pivotaltracker.com/story/show/137497509> Force User Password Change for UAA Internal Users This feature allows the administrator to force all users to change their password at next login time. This can be enforced on an individual user basis <http://docs.cloudfoundry.org/api/uaa/#force-user-password-to-expire>. This feature is multi-tenant and can be enabled per Identity Zone <http://docs.cloudfoundry.org/api/uaa/index.html#force-pasword-change-for-users> . - Add support for User Force Password Change at next login <https://www.pivotaltracker.com/story/show/131105231> - Provide ability to force password change for all users in the system <https://www.pivotaltracker.com/story/show/131113425> - Update the Login UI to honor Force Password Change <https://www.pivotaltracker.com/story/show/132023123> SAML Bearer Token support This feature enables SAML assertions to be exchanged for access tokens. This feature has been contributed by *SAP*. The documentation can be found here. <http://docs.cloudfoundry.org/api/uaa/#saml2-bearer-grant> - Feature: Add saml2 bearer grant <https://www.pivotaltracker.com/story/show/134877121> SQL Server Support In addition to PostGres and MySQL , UAA now supports SQL Server as a backend. This feature has been contributed by *Microsoft*. - Microsoft SQL Server Support as a backend <https://www.pivotaltracker.com/story/show/136315437> Detailed release notes are available here <https://github.com/cloudfoundry/uaa/releases/tag/3.10.0> Thanks, Sree Tummidi Staff Product Manager Identity - Pivotal Cloud Foundry |
|
|
|
Re: Loggregator Architecture Change: Independently Scalable Syslog
Marco Voelz
Thanks Adam for the permissions. The linked “Inception notes” document [1] seems to also have problems with permissions. Could you please also take care of that?
Thanks and warm regards Marco [1] https://docs.google.com/document/d/1LZCiFSe785BceKg9AM5btrnKucNfL11r1zobRuNy7Bk/edit From: Adam Hevenor <ahevenor(a)pivotal.io> Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: Wednesday, 1 February 2017 at 16:39 To: "cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org> Subject: [cf-dev] Re: Re: Loggregator Architecture Change: Independently Scalable Syslog Hi All - I have updated the sharing settings. Everyone should now be able to see and comment. Thanks Adam |
|
|
|
Dropping support for old versions of SSL and TLS in HAProxy and Gorouter
Shannon Coen
When TLS is enabled on Gorouter (router.enable_ssl: true; false by
default), it will currently accept connections using SSLv3, TLSv1.0, TLSv1.1, or TLSv1.2. The HAProxy in cf-release always has TLS enabled and will accept connections using TLSv1.0, TLSv1.1, or TLSv1.2. For security reasons, we would like to drop support in these components for all versions except TLSv1.2. Please let me know if you have a compelling use case for maintaining support for older versions using a manifest property. I recognize this could be an issue if apps on your deployments of CF must continue supporting clients that do not use TLSv1.2. Thank you, Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc. |
|
|
|
Re: Routing for Isolation Segments
Carlo Alberto Ferraris
Shannon,
I agree with Mike - we're in a similar situation where we already have implemented all network ACLs and FW rules - so also for us access control would be the priority, and partitioning nice to have. Thanks, Carlo |
|
|
|
Deprecation Notice: bosh-hm-forwarder is moving
Hi All -
In our continued effort for a clean the Loggregator code base we are moving another repo outside of Loggregator. The bosh-hm-forwarder can now be found at the following locations. New repo: https://github.com/cloudfoundry/bosh-hm-forwarder Bosh Release: http://bosh.io/releases/github.com/cloudfoundry/bosh-hm-forwarder-release?all=1 If you happen to reference the bosh-hm-forwarder in the loggregator repo you have until March 1st to update your references. I'll bump this thread again on March 1st when we delete this from our repo. Thanks Adam |
|
|
|
Recurring CAB and CF-extensions meetings
Michael Maximilien
fyi...
Since I got access to the CF Public Calendar (thanks Chip!) I moved the two recurring meetings (CAB and CF-extensions) to that calendar.
In theory, if you subscribed to the CF Public Calendar you should get these updates ASAP. If you added my calendar entry to yours then it should transfer. If not, delete the old and subscribe to the CF Public Calendar as that should give you everything CF related.
Sorry about this mishap. Hopefully, everyone now has the entries in their calendar. Just reminder, next CAB on Wed 02/15 @ 8a and next CF-extensions on Mon 02/27 @ 11a.
Talk to you then. Best,
------ dr.max ibm cloud labs silicon valley, ca maximilien.org |
|
|
|
Re: Deprecation Notice: loggregator statsd-injector is moving
Hi All -
Just a reminder. Today is the last day to update your reference to the statds-injector. We'll be deleting the version in the Loggregator repo today. You need to use this repo instead: https://github.com/cloudfoundry/statsd-injector-release Thanks Adam |
|
|
|
Re: Loggregator Architecture Change: Independently Scalable Syslog
Hi All -
I have updated the sharing settings. Everyone should now be able to see and comment. Thanks Adam |
|
|
|
CF-extensions PMC proposal process - DRAFT
Michael Maximilien
Hi, all,
In order to streamline, expedite, and control the quality of extensions proposal, we have created a process by which all proposal must adhere. I am asking your feedback on this process so we can make it official. Please find link below and please comment directly in Google Docs or reply to this email or ping me on Slack. It's short two pages so easy read. https://docs.google.com/document/d/1KaYuqNbPrr23d3OsAhi0NTwBNy-LRZK-FbN3LfBgqjw I would like to close the review on this by the next CAB call in third week of Feb (or before). All current proposals can opt to be grandfathered into this new process or not. Once official, please contact me with your decision if you are a proposal owner. I hope this small process addition to CF-extensions will result in more submissions and eventually more incubation into CF. All the best, dr.max ibm cloud labs sillicon valley, ca usa maximilien.org Sent from my iPhone |
|
|
|
Re: Loggregator Architecture Change: Independently Scalable Syslog
Marco Voelz
Dear Adam,
thanks for sharing the document. Could you please make it accessible for everyone? All I currently get is "You need permission Want in? Ask for access, or switch to an account with permission. Learn more<https://support.google.com/drive?p=requesting_access&hl=en>" Thanks and warm regards Marco From: Adam Hevenor <ahevenor(a)pivotal.io> Reply-To: "Discussions about Cloud Foundry projects and the system overall." <cf-dev(a)lists.cloudfoundry.org> Date: Tuesday, 31 January 2017 at 23:41 To: "cf-dev(a)lists.cloudfoundry.org" <cf-dev(a)lists.cloudfoundry.org> Subject: [cf-dev] Loggregator Architecture Change: Independently Scalable Syslog Hi All - The loggregator team is planning a track of work that results in some architectural changes to how syslog drains are implemented. I wanted to share our plans and solicit any feedback about this new approach. Brief: Developers and operators can use syslog drains to bind the logs of a specific app to a third party tool, but doing so puts additional strain on logs delivered through the firehose. These changes eliminate this burden and pave the way for more developer features related to syslog while keeping the same user experience. For more details please see: https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit#<https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit> Please let me know your comments, feedback or ideas about the proposal. Thanks! Adam |
|
|
|
CF-extensions monthly meeting notes - January 2017
Michael Maximilien
FYI...
Find summary of meeting here: https://docs.google.com/document/d/1RCMHYFQaB1oqdEKev-cVF2Rrr6qqCT9C6RmFFKmUxnI Best, dr.max ibm cloud labs sillicon valley, ca usa maximilien.org Sent from my iPhone |
|
|
|
Re: Loggregator Architecture Change: Independently Scalable Syslog
Vlad Iovanov
Cancel
toggle quoted message
Show quoted text
On Jan 31, 2017 14:42, "Adam Hevenor" <ahevenor(a)pivotal.io> wrote:
Hi All - |
|
|
|
Loggregator Architecture Change: Independently Scalable Syslog
Hi All -
The loggregator team is planning a track of work that results in some architectural changes to how syslog drains are implemented. I wanted to share our plans and solicit any feedback about this new approach. Brief: Developers and operators can use syslog drains to bind the logs of a specific app to a third party tool, but doing so puts additional strain on logs delivered through the firehose. These changes eliminate this burden and pave the way for more developer features related to syslog while keeping the same user experience. For more details please see: https://docs.google.com/document/d/1B31BWuPVGYIbQaEVfFhmTmp8_5t8RwGGHY_4q4unojI/edit# Please let me know your comments, feedback or ideas about the proposal. Thanks! Adam |
|
|
|
Re: cf-release 252 - Upcoming mutual TLS changes
Aakash Shah
Quick followup, we may have spoken too soon about the changes to the TPS
toggle quoted message
Show quoted text
job. Those changes are not slated to be in cf-release v252, but rather the release following it. Please leave "basic_auth_username" and "basic_auth_password" in your manifest until cf-release v253. Sorry if this caused any inconvenience, CAPI Team On Tue, Jan 31, 2017 at 11:56 AM, Aakash Shah <ashah(a)pivotal.io> wrote:
In the upcoming cf-release (v252), some components communicating with CC |
|
|
|
cf-release 252 - Upcoming mutual TLS changes
Aakash Shah
In the upcoming cf-release (v252), some components communicating with CC
via its internal API (for example: Loggregator, BBS, and TPS) will do so over mutual TLS. This is part of an effort to have all Cloud Foundry internal traffic be done over mutual TLS in lieu of basic auth. The CC and other components must now be configured with several new certificates to establish these mTLS connections. For most deployments, *use a shared CA between CF and Diego deployments*. Properties changes For a cf-release deployment manifest, the following properties are *required* for cloud_controller_ng and cloud_controller_worker jobs: properties: cc: mutual_tls: ca_cert: public_cert: private_key: Within your diego-release deployment manifest, the following properties are *required* for the tps job: properties: capi: tps: cc: ca_cert: client_cert: client_key: We have *removed* the following properties from the tps job: - properties.capi.tps.cc.basic_auth_username - properties.capi.tps.cc.basic_auth_password Generating certificates For instructions on how to generate the certificates for these properties, please see this doc: https://github.com/cloudfoundry/capi-release/ blob/develop/docs/tls-configuration.md We hope these changes are clear. If you run into trouble or have questions, please feel free to reach out to us on slack <https://cloudfoundry.slack.com/messages/capi/>! - CAPI team |
|
|
|
Re: Incubation proposal: Abacus Service Broker
Hi,
toggle quoted message
Show quoted text
Anyone that wants to join me & Max is more than welcome. Just use one of the ways below. Online meeting: https://apear.in/cf-abacus Slack channel: abacusdev.slack.com Phones: Participant Passcode: 362 314 3907 Country Number Mobile/Lync Bulgaria: 00 800 118 4451 tel:008001184451,,,3623143907# number not accessible from mobile Canada, Montreal: +1 514 669 5883 tel:+15146695883,,,3623143907# Canada, Toronto: +1 416 915 3225 tel:+14169153225,,,3623143907# Canada, Vancouver: +1 604 909 2086 tel:+16049092086,,,3623143907# Canada: 1 877 252 4916 tel:18772524916,,,3623143907# Germany, Frankfurt: +4969222210764 tel:+4969222210764,,,3623143907# Germany, Munich: +4989710424682 tel:+4989710424682,,,3623143907# Germany Mobile: 0800588 9331 tel:08005889331,,,3623143907# India, Bangalore: +91 80 6127 5055 tel:+918061275055,,,3623143907# India, Chennai: +91 44 6688 6114 tel:+914466886114,,,,3623143907# India, Delhi: +91 11 6641 1356 tel:+911166411356,,,3623143907# India, Gurgaon: +91 124 712 7900 tel:+911247127900,,,3623143907# India, Mumbai: +91 22 6150 1743 tel:+912261501743,,,3623143907# India: 1800 266 0327 tel:18002660327,,,,3623143907# UK,03: +44 330 336 6043 tel:+443303366043,,,3623143907# UK: 0800 368 0635 tel:08003680635,,,3623143907# UK (lo-call): 0845 545 0012 tel:08455450012,,,3623143907# US and Canada: 1-866-312-7353 tel:+18663127353,,,3623143907# US and Canada: 1-646-434-0499 tel:+16464340499,,,3623143907# US and Canada: 1-720-897-6637 tel:+17208976637,,,3623143907# US and Canada: 1-484-427-2544 tel:+14844272544,,,3623143907# Phone Type: Countries listed with a city are local access, all others are International Toll Free. Please use local access numbers whenever possible. Regards, Hristo Iliev 2017-01-25 11:33 GMT+02:00 Hristo Iliev <hsiliev(a)gmail.com>: Thanks Max. |
|
|