1. cf-dev@lists.cloudfoundry.org
  2. Messages
   Date   
Re: Proposal for Incubation in the Extensions PMC: MultiApps

Zach Robinson
 

Excited to see this proposed Nikolay!

Nikolay has been sharing this project with some of the core teams over the last couple of months.  We have even been giving some thought to adopting some of the behaviors and/or code from this extension into core CF.

Some aspects I think are especially interesting:
- declarative manifest behavior
- an opinionated packaging structure
- deployment orchestration

CAPI is especially excited to see whether the community takes to some of this tooling as potential guidance for future roadmap.

-Zach
CAPI Project Lead


On Tue, Mar 20, 2018 at 9:35 AM Nikolay Valchev <nikolay.valchev@...> wrote:

Hi All,

 

SAP is proposing MultiApps (aka CF MTA deploy service) for inclusion in the Extensions PMC as a new incubating project.

MultiApps is envisioned to provide the missing higher-level lifecycle management capabilities for distributed applications in Cloud Foundry. It proposes a new declarative application model and corresponding tools helping developers achieve the following goals:

  1. Describe explicitly the structure of my application, its constituent CF-apps, routes, services and other technical artifacts. Tools, interpreting this model, would automate deployments, achieving unified lifecycle of all application components and ensuring the consistency and completeness of the distributed application.   
  2. Declare the resources (e.g. service instances or APIs from other apps) my application depends on at runtime and/or deployment time. Tools would then check existence of required service instances, possibly allocating the missing ones and making the needed app bindings. Additionally tools would resolve dependent apps API information and inject it in requiring app env.
  3. Declare configuration variables (and their relations) which distinguish different deployments of my application. Tools would bind sub-components, automate deployment based on default settings, or request missing mandatory values interactively.

MultiApps is currently available on GitHub [1].

 

Details:

Project Name: MultiApps

Project Proposal: See [2].

Proposed Project Leads: Nikolay Valchev, SAP

Proposed Scope: See [2]

Development Operating Model: Dedicated committers (local)

Technical Approach: CF CLI plugin and server application automating lifecycle operations

Please let us know if you have any questions or feedback.

 

Best regards,

Nikolay Valchev

Development Architect and Product Owner, SAP

 

[1] https://github.com/SAP/cf-mta-deploy-service

[2] https://docs.google.com/document/d/1TCx_2gv2_n-StcV4lzbbaD4rma9HfaRG7O9wb6-egk4

 
Proposal for Incubation in the Extensions PMC: MultiApps

Nikolay Valchev
 

Hi All,

 

SAP is proposing MultiApps (aka CF MTA deploy service) for inclusion in the Extensions PMC as a new incubating project.

MultiApps is envisioned to provide the missing higher-level lifecycle management capabilities for distributed applications in Cloud Foundry. It proposes a new declarative application model and corresponding tools helping developers achieve the following goals:

  1. Describe explicitly the structure of my application, its constituent CF-apps, routes, services and other technical artifacts. Tools, interpreting this model, would automate deployments, achieving unified lifecycle of all application components and ensuring the consistency and completeness of the distributed application.   
  2. Declare the resources (e.g. service instances or APIs from other apps) my application depends on at runtime and/or deployment time. Tools would then check existence of required service instances, possibly allocating the missing ones and making the needed app bindings. Additionally tools would resolve dependent apps API information and inject it in requiring app env.
  3. Declare configuration variables (and their relations) which distinguish different deployments of my application. Tools would bind sub-components, automate deployment based on default settings, or request missing mandatory values interactively.

MultiApps is currently available on GitHub [1].

 

Details:

Project Name: MultiApps

Project Proposal: See [2].

Proposed Project Leads: Nikolay Valchev, SAP

Proposed Scope: See [2]

Development Operating Model: Dedicated committers (local)

Technical Approach: CF CLI plugin and server application automating lifecycle operations

Please let us know if you have any questions or feedback.

 

Best regards,

Nikolay Valchev

Development Architect and Product Owner, SAP

 

[1] https://github.com/SAP/cf-mta-deploy-service

[2] https://docs.google.com/document/d/1TCx_2gv2_n-StcV4lzbbaD4rma9HfaRG7O9wb6-egk4

 
FINAL REMINDER: CAB call for March is Wednesday 03/21 @ 8a PST

Michael Maximilien
 

FYI...

See below. Zoom soon. Best,

dr.max
ibm ☁ 
silicon valley, ca



dr.max
ibm ☁ 
silicon valley, ca


On Mar 14, 2018, at 12:06 PM, Michael Maximilien <maxim@...> wrote:

FYI...
 
Reminder that the CAB call for March is scheduled for next Wednesday 03/21 @ 8a PST.
 
WIP agenda and zoom info in [1] but summary here:
  1. CFF updates.
  2. Highlights from different PMCs and teams.
  3. Community talks:
a. MS SQL Service Broker proposal [3] by Jared Gordon of Pivotal and team (Pivotal and Microsoft)
b. CF-Dev [4] proposal [5] by Stephen Levine of Pivotal
 
I will send one more reminder next week on this list. Zoom soon.
 
Best,

PS: next month the CAB call will be during CF Summit in Boston and we will try to get a room so we can do it live! If you will be at summit, plan to join us.
 
------
dr.max
ibm ☁ 
silicon valley, ca
 
Re: A New Packaging Approach - CLI Tools Pushing Apps and the Story about the #loggregator “space drain” experiment #loggregator

Mike Youngstrom
 

It is an interesting idea/concept.

I'd say the auth model is a significant Con and potential large hurdle.  I'm assuming the username and password passed with the cli is then used by the pushed app to continually query the space for new apps and bind the service, correct?  I'm interested in seeing what UAA and Perm could come up with to improve this.  It seems you'd either need to dynamically generate a service account with developer access to the space.  Or figure out some way to give apps running in a space the ability to create a token to do management operations in the space it exists in.  Neither seems very simple.

Another Con would be lack of operator control over upgrading such a feature.  If new versions this app are released end users would need to know to run the command again to upgrade it.  Might be tricky as CC APIs evolve and such.  Anything that the user doesn't feel like they have ownership over I as the operator would like to be able to upgrade for them.  A CLI plugin pushed app sits in the middle somewhere.

It seems to me a simpler approach to the original problem of sending all logs for apps in a space to a drain could be solved with a service broker.  This broker would need CF_ADMIN client credentials but could simply scan all spaces for instances of itself then binding itself to all apps in spaces where it finds itself.  As a broker it could be upgraded by the operators and would provide less permission complexities.

Thoughts?

Mike

On Mon, Mar 19, 2018 at 4:17 PM, Adam Hevenor <ahevenor@...> wrote:

Back Story
The Loggregator team has recently been seeing a ton of benefit from developing CLI plugins. Specifically they are quick to develop, and distribute and lend themselves well to rapid iteration based on feedback. Developing our noisy neighbor nozzle we worked closely with the Pivotal early access program to meaningfully shape the final product that we eventually posted here. This feedback loop helped us focus on the trying to solve specific packaging UX problems with a plugin and arrived at a new techniques that packaged apps along with a CLI plugin. We have since taken those ideas a step further.

Space Drain
We recently started enhancing the "drain" functionality of Loggregator  with a plugin and it’s been a long standing idea to allow app developers to drain their whole space. If you look at the doc, you’ll see that multiple teams weighed in and the effort was shelved due to a break in conventions and a lack of clarity (at the time) around the precise persona. In my mind I filed this under high value/high complexity and figured we’d come back to it eventually.

But our noisy neighbor nozzle experience got us thinking. What if we we packaged an application with the CLI that was pushed when you ran a command, and that application managed the drain bindings for all the apps in your space. All of a sudden an initiative that involved 3 or more teams, was simplified into a 4 or 5 points in our backlog. Part of the work was figuring out some of the packaging technique so we ended up cutting a version of this in the latest cf-drain release. 

(It’s helpful for context to try this out which you can do so with the following command.)

Feedback & Pro / Cons
I am posting this because I want feedback on this approach before taking it further. The pattern is a liberating one and we have several ideas that we are considering executing on that follow this same approach. 

Pro’s

  • Rapid Iteration with established versioning approach
  • Ability to deliver pushable apps without compile instructions or OS specific scripts
  • Self Service for App Developers

Con’s

  • The auth model seems in-elegant. (UAA Team has been providing some feedback on this and I hope to improve this experience)
  • Self Service for App Developers (I am listing this as a con also because controlling operators may find this problematic)
A New Packaging Approach - CLI Tools Pushing Apps and the Story about the #loggregator “space drain” experiment #loggregator

Adam Hevenor
 

Back Story
The Loggregator team has recently been seeing a ton of benefit from developing CLI plugins. Specifically they are quick to develop, and distribute and lend themselves well to rapid iteration based on feedback. Developing our noisy neighbor nozzle we worked closely with the Pivotal early access program to meaningfully shape the final product that we eventually posted here. This feedback loop helped us focus on the trying to solve specific packaging UX problems with a plugin and arrived at a new techniques that packaged apps along with a CLI plugin. We have since taken those ideas a step further.

Space Drain
We recently started enhancing the "drain" functionality of Loggregator  with a plugin and it’s been a long standing idea to allow app developers to drain their whole space. If you look at the doc, you’ll see that multiple teams weighed in and the effort was shelved due to a break in conventions and a lack of clarity (at the time) around the precise persona. In my mind I filed this under high value/high complexity and figured we’d come back to it eventually.

But our noisy neighbor nozzle experience got us thinking. What if we we packaged an application with the CLI that was pushed when you ran a command, and that application managed the drain bindings for all the apps in your space. All of a sudden an initiative that involved 3 or more teams, was simplified into a 4 or 5 points in our backlog. Part of the work was figuring out some of the packaging technique so we ended up cutting a version of this in the latest cf-drain release. 

(It’s helpful for context to try this out which you can do so with the following command.)

Feedback & Pro / Cons
I am posting this because I want feedback on this approach before taking it further. The pattern is a liberating one and we have several ideas that we are considering executing on that follow this same approach. 

Pro’s

  • Rapid Iteration with established versioning approach
  • Ability to deliver pushable apps without compile instructions or OS specific scripts
  • Self Service for App Developers

Con’s

  • The auth model seems in-elegant. (UAA Team has been providing some feedback on this and I hope to improve this experience)
  • Self Service for App Developers (I am listing this as a con also because controlling operators may find this problematic)
Re: Feedback request: Disable logging Client IP’s in the Gorouter logs for compliance with the EU General Data Protection Regulation (GDPR)

Stefan Mayr
 

Hi,

Am 13.03.2018 um 00:39 schrieb Shubha Anjur Tupil:
Hello everyone, 

In lieu of The EU General Data Protection Regulation (GDPR), the routing
team is investigating adding manifest properties to allow an operator to
disable logging the client IP's in the |X-Forwarded-For| header in the
access and error logs for Gorouter.

Enforcement of The EU General Data Protection Regulation (GDPR)
(https://www.eugdpr.org/) begins May 28th and imposes steep fines. This
law says that companies will be fined if they are capturing PII. The
Gorouter currently captures Client IP addresses that are included in
that definition. We are exploring manifest properties to allow operators
to disable logging the originating client IP.

We need help weighing the options given the use-cases.

*Use-cases*:

#1. L3 Load Balancer e.g. Amazon NLB in front of the Gorouter 
The client IP is logged and the X-Forwarded-For header might have the
originating client IP if an intermediary component or the originating
client is adding the header.

#2. L7 Load Balancer e.g. Amazon NLB in front of the Gorotuer 
The client IP is the IP of the load balancer in front of the Gorouter,
but the X-Forwarded-For header has the originating client IP.

*Option1*: We have one manifest property to disable logging both the
X-Forwarded-For header and the Client IP in the Gorouter logs.

For use-case #1 this works, and there is only one manifest property to
disable all PII being logged by the Gorouter.

For use-case #2 this results in the operator losing the LB IP which
might be helpful for troubleshooting.

*Option2*: We have two separate manifest properties to disable logging
the X-Forwarded-For header and/or the Client IP in the Gorouter logs.
This is generally more flexible at the cost of user experience.

For use-case #1 this would mean that an operator would have to set two
manifest properties instead of one. Both these properties would need to
be exposed in Ops Man for PCF installations. It leads to a more
cumbersome user experience, adding to the already long list of options.

For use-case #2 this results in a better outcome for an operator in that
they still get the information on the LB the request came from, while
the originating client IP will not be logged.

Based on the information we have, we are not sure which experience is
better and which use-case to optimize for. Some questions we have

1. What type of LB is more popular in CF environments; L3 or L7? This
might help us optimize for Use-case #2 and go with Option #2.
Our deployment scenario is #2. The L7 load balancer inserts a
X-Forwarded-For header.

2. Is there a compelling reason from an operator perspective for
installations with a L7 load balancer, making it important to have
the Client IP (i.e. they would absolutely want to have Option #2 or
maybe don’t care and Option #1 would be ok)?
All external request to gorouter are coming through the L7 load
balancer. So for most debugging use cases the load balancer IP in
gorouter access log would not provide any value - but the client IP from
the X-Forwarded-For header does. This brings up another point: it is not
generally forbidden to store ip addresses for specific uses cases, at
least in germany. E.g, as far as I understand the current situation we
are allowed the store IP addresses for defense or debugging purpose for
a limited time if (!) this is documented in the public data privacy
statement. It looks like 1-2 weeks are generally acceptable for this use
case.

3. Does the user experience benefit by having just one option outweigh
the benefit of having the client IP for an operator with an L7 Load
Balancer? (Flexibility over Experience)
For us this would not provide any advantage to have seperate
configuration options. If we cannot limit the timeframe keept by
logrotation we would disable IP logging.

We would love to hear from you if you have thoughts on this.
This topics raises some other questions about the IP addresses being
passed around in multiple components. gorouter creates the RTR log
messages that we can read from loggregator. Does loggregator buffer
those messages or disk or is this only kept in memory? When is this
information purged from loggregator?
Next component we see is the buildpack. Some also show classic access
log information on stdout. Did anybody check if none of the buildpacks
writes this information to disk?


Thanks, 

Shannon Coen & Shubha Anjur Tupil
Product Managers, CF Routing
Regards,

Stefan
Re: Cloud Foundry and Kubernetes Integration Efforts

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

Hello Shannon,

 

I think you are referring to my original mail that was pointing to four documents in total, correct?

 

 

Please let me know if you continue to face issues with commenting in any of the docs.

 

Thanks in advance,

Bernd

 

From: <cf-dev@...> on behalf of Shannon Coen <scoen@...>
Reply-To: "cf-dev@..." <cf-dev@...>
Date: Friday, 16. March 2018 at 18:59
To: "cf-dev@..." <cf-dev@...>
Subject: Re: [cf-dev] Cloud Foundry and Kubernetes Integration Efforts

 

Hello Bernd,

 

Would you please grant anyone with the link permissions to comment on these docs?

 

Thank you.


Shannon Coen

Product Manager, Cloud Foundry

Pivotal, Inc.

 

On Fri, Jan 5, 2018 at 4:03 PM, Adam Hevenor <ahevenor@...> wrote:

Bernd - 

Happy New Year! 

I linked another proposal I have been working on that expands on the ideas of containerizing loggregator and the benefits of "unified logging" (or I like to refer to it as egress). This has benefits beyond PKS, which include stand alone service, multi-foundation and general observability mind share. 

These ideas have really gotten me excited and I think there is a strong case for making unified egress a first class concern of both platforms and we are bubbling with ideas to improve it further. Of course I am now also probably guilty of imagining an attractive end state without thinking through all of the steps along the way - but it feels like we are taking those first steps by sharing these ideas. 

I'll reach out separately to coordinate some offline communications on this subject. 

Adam 

 
Identifying CF Resources

Christopher Brown <cbrown@...>
 

Hi all,

The Permissions component ("Perm") we're building to store and evaluate roles for Cloud Foundry needs to be able to identify resources across component boundaries so that it knows which policies to apply for any given permission check. AWS does this using their ARN scheme.

I'd like to work out if something like this would be the correct approach for Perm. We'd like to find something which can identify resources across foundations and encode the object hierarchy into the resource identifier. For example, an application inside PWS could be identified by:

pws:cc:application/[org guid]/[space guid]/[app guid]

I don't want to get too into the weeds of the exact format yet but if you:
  • ...have already built something like this to help with cross-foundation operations (or any other reason)
  • ...are looking into working on something like this to help with a different problem
then I'd be interested in talking with you about this requirement and what the solution could look like.

All the best,
Christopher
CF Permissions PM
Re: Cloud Foundry and Kubernetes Integration Efforts

Shannon Coen
 

Hello Bernd,

Would you please grant anyone with the link permissions to comment on these docs?

Thank you.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Fri, Jan 5, 2018 at 4:03 PM, Adam Hevenor <ahevenor@...> wrote:
Bernd - 

Happy New Year! 

I linked another proposal I have been working on that expands on the ideas of containerizing loggregator and the benefits of "unified logging" (or I like to refer to it as egress). This has benefits beyond PKS, which include stand alone service, multi-foundation and general observability mind share. 

These ideas have really gotten me excited and I think there is a strong case for making unified egress a first class concern of both platforms and we are bubbling with ideas to improve it further. Of course I am now also probably guilty of imagining an attractive end state without thinking through all of the steps along the way - but it feels like we are taking those first steps by sharing these ideas. 

I'll reach out separately to coordinate some offline communications on this subject. 

Adam 


Re: Feature Narrative - Isolated Loggregator Components

Mike Youngstrom
 

Thanks for posting this Adam.  I love the direction and improvements the Loggregator team has been working towards lately!  Isolation segment support will be yet another plus.

Mike

On Tue, Mar 13, 2018 at 12:26 PM, Adam Hevenor <ahevenor@...> wrote:
One of the benefits we see of having re-engineered the persistance layer of Loggregator (see log-cache announcement) is a simpler architecture which can be deployed to multiple times within Cloud Foundry Application Runtime. This makes the concept of isolation segments one that works nicely with Loggregator, which is a feature we have received consistent feedback on over the last year. 

For more details about the problems this solved and work proposed please read the following Feature Narrative. 
Re: Designing a new routing tier for Cloud Foundry

Shannon Coen
 

Re: Announcing DNS-based service discovery for container networking

Michael Maximilien
 

Congrats to the team and to you Usha for getting this done with a heterogeneous group. Looks really good to me, well done. 

Yet another feature that’s helping CF push the envelop of cloud application development and management, while remaining simple and easy to use. Cheers,

Max

On Thu, Mar 15, 2018 at 9:54 AM Usha Ramachandran <uramachandran@...> wrote:

Hello everyone,


We are excited to announce the availability of DNS-based polyglot service discovery on Cloud Foundry. With this feature, Cloud Foundry apps in all languages and frameworks can leverage container-to-container networking.


Many Cloud Foundry teams came together to deliver this feature. A big thank you to CAPI, Routing, Diego, BOSH, CLI and Release Integration teams for their participation in conversations and cross-team development.


To find out more about the feature and the use cases, read this blog post. To try it out, follow our instructions to deploy with cf-deployment v1.17.0 or later.


Polyglot service discovery is currently an experimental feature. It is  deployed to Pivotal Web Services, where we will watch it and make generally available if all goes well.


We look forward to your feedback! Please reach out to us on #container-networking on Cloud Foundry slack if you have any questions!


Thank you,

CF Networking Team



--
dr.max Sent from my iPhone http://maximilien.org
CF routing-release 0.174.0

Shubha Anjur Tupil
 

Hi, 

We cut a release yesterday evening. The release included a fix for an issue we discovered on PWS while rolling out a feature to enable TLS between Gorouter and backend applications. 

- When a connection to a TLS enabled backend fails, Gorouter tries to send a request to another backend of the app before returning a response to the client. In an environment where some backends are TLS enabled and some are not, if the Gorouter first chooses a TLS enabled backend and fails, and if it subsequently chooses a non TLS backend, then it will appropriately use a plain text request. [details](https://www.pivotaltracker.com/story/show/155981374)


Regards, 
Shubha & Shannon
Product Manager, Routing
Announcing DNS-based service discovery for container networking

Usha Ramachandran
 

Hello everyone,


We are excited to announce the availability of DNS-based polyglot service discovery on Cloud Foundry. With this feature, Cloud Foundry apps in all languages and frameworks can leverage container-to-container networking.


Many Cloud Foundry teams came together to deliver this feature. A big thank you to CAPI, Routing, Diego, BOSH, CLI and Release Integration teams for their participation in conversations and cross-team development.


To find out more about the feature and the use cases, read this blog post. To try it out, follow our instructions to deploy with cf-deployment v1.17.0 or later.


Polyglot service discovery is currently an experimental feature. It is  deployed to Pivotal Web Services, where we will watch it and make generally available if all goes well.


We look forward to your feedback! Please reach out to us on #container-networking on Cloud Foundry slack if you have any questions!


Thank you,

CF Networking Team
Re: CF CLI v6.35.0 Release Today - service instance sharing; client credentials

Gowrisankar M
 

Hello All,

CF services sharing when it will be available for user-provided services?

BRs,Gowrisankar

On Thu, Mar 15, 2018 at 12:53 AM, Matthias Winzeler <matthias.winzeler@...> wrote:
Hi Tian

Thanks for the information - this sounds good. 
We're looking forward for clients with user permission since this will solve the issue with SAML federated users who want to interact with the API interactively (currently not possible, so we create local users for them).

-Matthias

2018-03-14 20:02 GMT+01:00 Tian Wang <tiwang@...>:
Hi Matthias,

The service accounts feature today works for global scopes on clients created in UAA such as `cloud_controller.admin` and `cloud_controller.admin_read_only`.

The current plan is to integrate down the line with the Perm project which will provide the ability to assign clients with space and org fine-grained authorizations, so that they can act essentially the same as a user.

Regards,

Tian

On Sat, Mar 10, 2018 at 12:52 AM, Matthias Winzeler <matthias.winzeler@...> wrote:
Hi Jay

The service accounts feature sounds very exciting. How does it work exactly? 

I guess I have to create a user on UAA with client credentials grant type (i.e. with uaac) first.
How can I then permit this client to orgs and spaces so that he can interact with CF like a user?

-Matthias

2018-03-10 2:15 GMT+01:00 Dr Nic Williams <drnicwilliams@...>:

> Service brokers must explicitly enable service instance sharing by setting a flag in their service-level metadata object. This allows service instances, of any service plan, to be shared across organizations and spaces. The "shareable" flag must be set to true in the service-level metadata to enable service instance sharing. If the flag is set to false or is absent, sharing is disabled.

From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Saturday, March 10, 2018 11:14:01 AM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI v6.35.0 Release Today - service instance sharing; client credentials
 
Reading the links thru to info in services supporting sharing - what were the ideas behind requiring service implementors to opt in; rather than leave this to CF administrators or space/org administrators to enable?

From: cf-dev@... <cf-dev@...> on behalf of Jay Badenhope <jbadenhope@...>
Sent: Saturday, March 10, 2018 8:53:18 AM
To: cf-dev@...
Subject: [cf-dev] CF CLI v6.35.0 Release Today - service instance sharing; client credentials
 
The CF CLI team released version 6.35.0 today. Yay!


Service Instance Sharing

This cf CLI feature includes two new commands, share-service and unshare-service, to enable you to share service instances between spaces in the same or different orgs. Additional details here. We welcome your feedback on the new implementation.

To help you track where a service instance is shared to or from, we refactored and updated the service command.

Service Account Authentication (Client Credentials)

It is now possible to authenticate with only a client ID and a secret using the auth command with a new --client-credentials flag. Before this release, users could only log in as a user (i.e. username & password with either default client id, or custom client id & secret). That meant "fake" users needed to be prepared for CI environments and scripts ("tiles" self-registration).

push Fixes and Enhancements

  • v2-push no longer accepted (previous release merged v2-push into push)
  • Fixes problem where existing routes with customer hosts were ignored on push, #1321

Other Fixes and Enhancements

  • Fixed problem where wildcards weren't allowed in routes section of app manifest, deployment #399

Plugin Updates

Going forward, we ask that every plugin name matches its command name so it can be installed and uninstalled with the same name.

  • Updated Event Alerts Plugin to 0.0.1, #198, then removed that plugin, #211
  • Updated top Plugin to 0.9.3, #210
  • Updated service-use to 1.2.2 with matching command and plugin names #213

Refactored commands

  • services to enable an upcoming feature
  • service (see above)
  • logout to enable clearing of client credentials for Service Account Authentication (see above); will now also show user name during logout for consistency with other commands

Release contributors: An Yu, Nick Wei, Sebastian Vidrio, Anande Gaitonde, Jay Badenhope, and special guest Kevin Middleton. Thanks also to our partners on the CAPI, SAPI, and UAA teams.


--

Jay Badenhope

Product Manager, CF CLI
Pivotal Labs
LinkedIn | Twitter





--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...





--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...
CF CLI v6.35.1 Release Today - patch for services issue

Jay Badenhope <jbadenhope@...>
 

Fixed regressions
  • Corrected issue so `service`, `services`, and `share-service` commands no longer fail with a JSON unmarshal error for certain service broker configurations; was also reported as Github issue #1342

Other fixes
  • Changed all warnings, including experimental warnings for v3 commands, so they now output to STDERR to make debugging easier
Thanks for reading.
Jay
--

Jay Badenhope

Product Manager, CF CLI
Pivotal Labs
+1.510.517.6973 
LinkedIn | Twitter
Re: CF CLI v6.35.0 Release Today - service instance sharing; client credentials

Matthias Winzeler
 

Hi Tian

Thanks for the information - this sounds good. 
We're looking forward for clients with user permission since this will solve the issue with SAML federated users who want to interact with the API interactively (currently not possible, so we create local users for them).

-Matthias

2018-03-14 20:02 GMT+01:00 Tian Wang <tiwang@...>:

Hi Matthias,

The service accounts feature today works for global scopes on clients created in UAA such as `cloud_controller.admin` and `cloud_controller.admin_read_only`.

The current plan is to integrate down the line with the Perm project which will provide the ability to assign clients with space and org fine-grained authorizations, so that they can act essentially the same as a user.

Regards,

Tian

On Sat, Mar 10, 2018 at 12:52 AM, Matthias Winzeler <matthias.winzeler@...> wrote:
Hi Jay

The service accounts feature sounds very exciting. How does it work exactly? 

I guess I have to create a user on UAA with client credentials grant type (i.e. with uaac) first.
How can I then permit this client to orgs and spaces so that he can interact with CF like a user?

-Matthias

2018-03-10 2:15 GMT+01:00 Dr Nic Williams <drnicwilliams@...>:

> Service brokers must explicitly enable service instance sharing by setting a flag in their service-level metadata object. This allows service instances, of any service plan, to be shared across organizations and spaces. The "shareable" flag must be set to true in the service-level metadata to enable service instance sharing. If the flag is set to false or is absent, sharing is disabled.

From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Saturday, March 10, 2018 11:14:01 AM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI v6.35.0 Release Today - service instance sharing; client credentials
 
Reading the links thru to info in services supporting sharing - what were the ideas behind requiring service implementors to opt in; rather than leave this to CF administrators or space/org administrators to enable?

From: cf-dev@... <cf-dev@...> on behalf of Jay Badenhope <jbadenhope@...>
Sent: Saturday, March 10, 2018 8:53:18 AM
To: cf-dev@...
Subject: [cf-dev] CF CLI v6.35.0 Release Today - service instance sharing; client credentials
 
The CF CLI team released version 6.35.0 today. Yay!


Service Instance Sharing

This cf CLI feature includes two new commands, share-service and unshare-service, to enable you to share service instances between spaces in the same or different orgs. Additional details here. We welcome your feedback on the new implementation.

To help you track where a service instance is shared to or from, we refactored and updated the service command.

Service Account Authentication (Client Credentials)

It is now possible to authenticate with only a client ID and a secret using the auth command with a new --client-credentials flag. Before this release, users could only log in as a user (i.e. username & password with either default client id, or custom client id & secret). That meant "fake" users needed to be prepared for CI environments and scripts ("tiles" self-registration).

push Fixes and Enhancements

  • v2-push no longer accepted (previous release merged v2-push into push)
  • Fixes problem where existing routes with customer hosts were ignored on push, #1321

Other Fixes and Enhancements

  • Fixed problem where wildcards weren't allowed in routes section of app manifest, deployment #399

Plugin Updates

Going forward, we ask that every plugin name matches its command name so it can be installed and uninstalled with the same name.

  • Updated Event Alerts Plugin to 0.0.1, #198, then removed that plugin, #211
  • Updated top Plugin to 0.9.3, #210
  • Updated service-use to 1.2.2 with matching command and plugin names #213

Refactored commands

  • services to enable an upcoming feature
  • service (see above)
  • logout to enable clearing of client credentials for Service Account Authentication (see above); will now also show user name during logout for consistency with other commands

Release contributors: An Yu, Nick Wei, Sebastian Vidrio, Anande Gaitonde, Jay Badenhope, and special guest Kevin Middleton. Thanks also to our partners on the CAPI, SAPI, and UAA teams.


--

Jay Badenhope

Product Manager, CF CLI
Pivotal Labs
LinkedIn | Twitter





--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...





--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...
REMINDER: CAB call for March is Wednesday 03/21 @ 8a PST

Michael Maximilien
 

FYI...
 
Reminder that the CAB call for March is scheduled for next Wednesday 03/21 @ 8a PST.
 
WIP agenda and zoom info in [1] but summary here:
  1. CFF updates.
  2. Highlights from different PMCs and teams.
  3. Community talks:
a. MS SQL Service Broker proposal [3] by Jared Gordon of Pivotal and team (Pivotal and Microsoft)
b. CF-Dev [4] proposal [5] by Stephen Levine of Pivotal
 
I will send one more reminder next week on this list. Zoom soon.
 
Best,

PS: next month the CAB call will be during CF Summit in Boston and we will try to get a room so we can do it live! If you will be at summit, plan to join us.
 
------
dr.max
ibm ☁ 
silicon valley, ca
 
Re: CF CLI v6.35.0 Release Today - service instance sharing; client credentials

Tian Wang
 

Hi Matthias,

The service accounts feature today works for global scopes on clients created in UAA such as `cloud_controller.admin` and `cloud_controller.admin_read_only`.

The current plan is to integrate down the line with the Perm project which will provide the ability to assign clients with space and org fine-grained authorizations, so that they can act essentially the same as a user.

Regards,

Tian

On Sat, Mar 10, 2018 at 12:52 AM, Matthias Winzeler <matthias.winzeler@...> wrote:
Hi Jay

The service accounts feature sounds very exciting. How does it work exactly? 

I guess I have to create a user on UAA with client credentials grant type (i.e. with uaac) first.
How can I then permit this client to orgs and spaces so that he can interact with CF like a user?

-Matthias

2018-03-10 2:15 GMT+01:00 Dr Nic Williams <drnicwilliams@...>:

> Service brokers must explicitly enable service instance sharing by setting a flag in their service-level metadata object. This allows service instances, of any service plan, to be shared across organizations and spaces. The "shareable" flag must be set to true in the service-level metadata to enable service instance sharing. If the flag is set to false or is absent, sharing is disabled.

From: cf-dev@... <cf-dev@...> on behalf of Dr Nic Williams <drnicwilliams@...>
Sent: Saturday, March 10, 2018 11:14:01 AM
To: cf-dev@...
Subject: Re: [cf-dev] CF CLI v6.35.0 Release Today - service instance sharing; client credentials
 
Reading the links thru to info in services supporting sharing - what were the ideas behind requiring service implementors to opt in; rather than leave this to CF administrators or space/org administrators to enable?

From: cf-dev@... <cf-dev@...> on behalf of Jay Badenhope <jbadenhope@...>
Sent: Saturday, March 10, 2018 8:53:18 AM
To: cf-dev@...
Subject: [cf-dev] CF CLI v6.35.0 Release Today - service instance sharing; client credentials
 
The CF CLI team released version 6.35.0 today. Yay!


Service Instance Sharing

This cf CLI feature includes two new commands, share-service and unshare-service, to enable you to share service instances between spaces in the same or different orgs. Additional details here. We welcome your feedback on the new implementation.

To help you track where a service instance is shared to or from, we refactored and updated the service command.

Service Account Authentication (Client Credentials)

It is now possible to authenticate with only a client ID and a secret using the auth command with a new --client-credentials flag. Before this release, users could only log in as a user (i.e. username & password with either default client id, or custom client id & secret). That meant "fake" users needed to be prepared for CI environments and scripts ("tiles" self-registration).

push Fixes and Enhancements

  • v2-push no longer accepted (previous release merged v2-push into push)
  • Fixes problem where existing routes with customer hosts were ignored on push, #1321

Other Fixes and Enhancements

  • Fixed problem where wildcards weren't allowed in routes section of app manifest, deployment #399

Plugin Updates

Going forward, we ask that every plugin name matches its command name so it can be installed and uninstalled with the same name.

  • Updated Event Alerts Plugin to 0.0.1, #198, then removed that plugin, #211
  • Updated top Plugin to 0.9.3, #210
  • Updated service-use to 1.2.2 with matching command and plugin names #213

Refactored commands

  • services to enable an upcoming feature
  • service (see above)
  • logout to enable clearing of client credentials for Service Account Authentication (see above); will now also show user name during logout for consistency with other commands

Release contributors: An Yu, Nick Wei, Sebastian Vidrio, Anande Gaitonde, Jay Badenhope, and special guest Kevin Middleton. Thanks also to our partners on the CAPI, SAPI, and UAA teams.


--

Jay Badenhope

Product Manager, CF CLI
Pivotal Labs
LinkedIn | Twitter





--
Matthias Winzeler
Mattenenge 8
3011 Bern
mailto: matthias.winzeler@...
Windows Acceptance Tests

Ashley Hathaway
 

Hello all!


This is a heads up that the Garden Windows team has completed simplifying our test suite by moving Windows Acceptance Tests (WATs) into CF Acceptance Tests (CATs). CATs can now be configured to run tests against a CF deployment with Windows cells.


The WATs repo will be moved into the cloudfoundry-attic in 60 days (mid-May). We recommend within this time if you can move off WATs please do so.


For any feedback or thoughts please feel free to reach out. We're also available on the CF #garden-windows Slack


giphy.gif


Thanks!

The Garden Windows Team
1521 - 1540 of 9398