Date   

Re: Sample .NET hello_world app

Chris Clark
 

Hi Zach,

Disregard that last message. Paul found the bug, fixed it. Video is
playing correctly now and looks great. Thank you!

-Chris

On Thu, Aug 24, 2017 at 7:32 PM, Zach Brown <zbrown(a)pivotal.io> wrote:

Hey Chris

Noticed the .NET ascii video is up on cloudfoundry.org/platform.
There seems to be a formatting issue with this one too. I think it has to
do with the number of lines in the terminal.
It seems like only 20 lines are being displayed.

The net result is that at the very end, the last couple of lines where it
curls the new endpoint and the result is displayed get completely cut off.

Happy to create another one with different terminal settings if that's the
answer. (My terminal was set to 80x25).



On Mon, Aug 21, 2017 at 9:01 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Zach, thanks again for the .NET video!

Dr. Max, once we have that up, and the Go video fixed, I'll follow up
here with links to all.



On Mon, Aug 21, 2017 at 11:46 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Graham,

Thanks for catching that, and for your suggestions on the wording above!

-Chris

On Fri, Aug 18, 2017 at 7:43 AM, Graham Bleach <
graham.bleach(a)digital.cabinet-office.gov.uk> wrote:



On 17 August 2017 at 20:58, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

A while back I'd asked for help with a few sample apps to go on the
CF website. Thank you to everyone who helped out with that! They are up,
here: https://www.cloudfoundry.org/platform/.
These look pretty good and will be great for showing people how easy it
is to get started.

In the go demo video when the code's being typed into an editor it
seems to have a few linebreaks mid-line-of-code.

I think that the line "deployed in container images on any
infrastructure", would be more correct if it said "deployed in containers
on a choice of cloud infrastructures" - I think "container image" means
something more like a Docker/OCI image than a running container, and there
are *some* restrictions on which IaaS provider it can be deployed on,
although it's a pretty wide choice :)

Other than that, it looks very good.

Cheers,
Graham

--

*Zach Brown* | Strategic Product Owner

650-954-0427 <(650)%20954-0427> - mobile

zbrown(a)pivotal.io

<http://pivotal.io>



Re: Sample .NET hello_world app

Chris Clark
 

Hi Zach,

Nice catch. I hadn't been told the video was up yet.
Asciinema is pretty cool and also frequently annoying, it seems.

I looked at the json file for your video, and the curl and response are in
there. Also, looking at my terminal (which 2 of the videos were recorded
on), my defaults are 80 x 24. I'm not convinced that the # of lines is the
problem, but I also don't have a better hypothesis at this point. I'm
going to check with Paul, our web dev who's been working on this, and see
if he has any thoughts.

In the meantime, if you wanted to rerecord with 20 rows showing, I am
certainly not opposed.

Thanks again for your help.

On Thu, Aug 24, 2017 at 7:32 PM, Zach Brown <zbrown(a)pivotal.io> wrote:

Hey Chris

Noticed the .NET ascii video is up on cloudfoundry.org/platform.
There seems to be a formatting issue with this one too. I think it has to
do with the number of lines in the terminal.
It seems like only 20 lines are being displayed.

The net result is that at the very end, the last couple of lines where it
curls the new endpoint and the result is displayed get completely cut off.

Happy to create another one with different terminal settings if that's the
answer. (My terminal was set to 80x25).



On Mon, Aug 21, 2017 at 9:01 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Zach, thanks again for the .NET video!

Dr. Max, once we have that up, and the Go video fixed, I'll follow up
here with links to all.



On Mon, Aug 21, 2017 at 11:46 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Graham,

Thanks for catching that, and for your suggestions on the wording above!

-Chris

On Fri, Aug 18, 2017 at 7:43 AM, Graham Bleach <
graham.bleach(a)digital.cabinet-office.gov.uk> wrote:



On 17 August 2017 at 20:58, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

A while back I'd asked for help with a few sample apps to go on the
CF website. Thank you to everyone who helped out with that! They are up,
here: https://www.cloudfoundry.org/platform/.
These look pretty good and will be great for showing people how easy it
is to get started.

In the go demo video when the code's being typed into an editor it
seems to have a few linebreaks mid-line-of-code.

I think that the line "deployed in container images on any
infrastructure", would be more correct if it said "deployed in containers
on a choice of cloud infrastructures" - I think "container image" means
something more like a Docker/OCI image than a running container, and there
are *some* restrictions on which IaaS provider it can be deployed on,
although it's a pretty wide choice :)

Other than that, it looks very good.

Cheers,
Graham

--

*Zach Brown* | Strategic Product Owner

650-954-0427 <(650)%20954-0427> - mobile

zbrown(a)pivotal.io

<http://pivotal.io>



Re: [Proposal] Sharing service instances across orgs and spaces

Matt McNeeney
 

Thanks for the feedback Mike, and great questions! We're currently working
off slightly different assumptions, but are working through these to
validate that they are the expected behaviour for the majority of users:

* Space developers in the 'owning' space (this is the way we've thought
about this too!) *would *be able to delete or unshare a shared service
instance with bindings, but they would get a warning in the CLI warning
them that this will automatically delete bindings in other spaces.

* Space developers can only bind and unbind to service instances that have
been shared into their space. In this first version they wouldn't be able
to remove the service instance from appearing in their space without asking
the sharer to unshare it.

* We've investigated a number of sharing permission models, including how
both CF admins and service broker authors want to control this. Initial
feedback has suggested that for most use cases, service brokers shouldn't
care where the binding is coming from (it looks the same to them). There
are edge cases here with things like ASGs though which we will need to
consider.

* A space developer does *not *need to be a space developer in a space they
are sharing a service instance into. We're aware that this is a slightly
contentious decision, but our research has shown that this would not be
possible for many large-scale deployments. Our current thinking is that a
more explicit permissions model where admins can have more control over
sharing is a good path forward here, but we will likely look into that
after the first version with deployment-wide enabling and disabling of
sharing has been tested in the wild.

Hope that all makes sense. Happy to discuss any of these or other feedback
you have in further detail.

On Thu, Aug 24, 2017 at 4:40 PM Mike Youngstrom <youngm(a)gmail.com> wrote:

Great! I just thought of some questions and didn't see them listed in the
thread.

* I assume that the space that originally created the service would be a
kind of "owning" space right? So that space probably wouldn't be able to
delete the service unless it was unbound from other space's apps? Would
the service also need to be unshared before deleted?
* I assume a target space developer can unshare a service shared in their
space but not delete, right?
* Is it possible for a service to opt out or in of being shared perhaps
with a CF specific "requires" service permission? I'm thinking of Vivek
Anand's question about. If on create a service adds a security group to
the space creating it the broker would need to be changed to support
sharing.
* Does a space developer wishing to share a service need to be a space
developer in the space they are sharing into?

Great work keeping this much needed feature moving along!

Mike


On Thu, Aug 24, 2017 at 12:25 PM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Hi all,

I'm pleased to say that work will shortly be starting on the following
sharing service instances workflows:

$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE
$ cf unshare-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE

We will feature flag this work so that this can be enabled or disabled in
a Cloud Foundry deployment. Note that a key change from the workflows we
initially shared is that this feature will now be enabled/disabled for *all
services and service plans in a deployment*. The more explicit *enable-service-sharing
*workflows we initially proposed will likely be developed in a future
version of this feature. This stripped back permissions model will mean
that a Space Developer will be able to share a service instance in their
space into any other org and space.

Please let me know if anyone has any further thoughts on this. Your
feedback is always very much appreciated.

Many thanks,
Matt

On Mon, Jul 10, 2017 at 6:12 AM Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks all for the great feedback. There are a lot of good ideas here
that we will use to help guide the implementation of this.

Gabriel; the relationship service instances have with ASGs is
interesting. I don't think we should automatically modify security groups
when service instances are shared, as there could be security implications
in doing so. But this is definitely something we will look into in detail.

Jouke; permanent migrations of services isn't something we've taken into
account in this sharing proposal, however I can see the use cases. I wonder
if these could be mitigated via another solution to another CF CLI command,
for example, making backing up and restoring data services easier or
available to application developers.

Daniel; I believe that idea has been raised a few times but, as I'm sure
you know, breaking the services layer out of the cloud controller could be
very tricky and time consuming. Zach R would have more thoughts on this I'm
sure.

Dies; we believe enforcing service sharing to be enabled by default is a
more secure approach. I appreciate your point that right now application
developers can effectively workaround this and share services via passing
credentials and using *cf cups*, but we know that some CF users are
looking to hide credentials as best as possible. In a more secure world
where credentials are not visible to application developers and are
protected in something like CredHub, this new workflow would be the only
way to share services, and we'd like to ensure that this new workflow is as
secure as possible.


On Wed, Jul 5, 2017 at 6:37 AM tommyoshields71 <
tommyoshields71(a)gmail.com> wrote:

Tell me is this that expensive coin that I have

On Jul 4, 2017 12:40 AM, "Koper, Dies [via CF Dev]" <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=0>> wrote:

Hi Matt,



Can you explain the background of the service sharing enabling feature?

Who would want to disable this and for what reason?



I can imagine there are services that should not be bound to multiple
apps, maybe because of locking issues.

If that’s not a limitation/feature of the service, it may be a
constraint of the (initial) developer who created this service for a
single-user purpose.

For those cases, I feel it would make sense for the “enable” flag to
be an attribute of the service itself, or of the person (role) creating it.



How does the Org Manager come in play?

Wouldn’t I currently be copying the credentials over to another
org/person (maybe to another app developer) to store in a user-provided
service, so the additional enable step just creates an additional step
offering no protection?



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI




*From:* Matthew McNeeney [mailto:[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7097&i=0>]
*Sent:* Thursday, June 29, 2017 11:36 PM
*To:* Discussions about Cloud Foundry projects and the system overall.
<[hidden email] <http:///user/SendEmail.jtp?type=node&node=7097&i=1>>
*Subject:* [cf-dev] [Proposal] Sharing service instances across orgs
and spaces

Many Cloud Foundry users have expressed a desire to share service
instances across orgs and spaces. Whilst this could be considered an
anti-pattern for some data services, there are many use cases for which the
ability to do this is important. Two examples are sharing config servers
and messaging queues.



The workarounds that exist today (e.g. creating user-provided
services) require credentials to be passed around in some out-of-band way
and will prevent the platform from being able to do things like automatic
rotation of credentials in the future.



We'd like to propose a new workflow that looks like this:



$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE



A SpaceDeveloper in the target org/space will only be able to
bind/unbind to/from the shared service instance, and running cf
service will show that the service instance has been shared.



To manage any security concerns around this, a CF admin would have to
enable one-way sharing between two spaces with a command like:



$ cf enable-service-sharing SERVICE SOURCE_ORG SOURCE_SPACE TARGET_ORG
TARGET_SPACE





We'd love to hear feedback from the community on this proposal. If you
have any other use cases that this could help with, please let us know
about those too.



Matt



------------------------------
If you reply to this email, your message will be added to the
discussion below:

http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-Sharing-service-instances-across-orgs-and-spaces-tp7076p7097.html
To start a new topic under CF Dev, email [hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=1>
To unsubscribe from CF Dev, click here.
NAML
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
*IMG_20170704_081255.jpg* (1M) Download Attachment
<http://cf-dev.70369.x6.nabble.com/attachment/7101/0/IMG_20170704_081255.jpg>

------------------------------
View this message in context: Re: [cf-dev] Re: [Proposal] Sharing
service instances across orgs and spaces
<http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Re-Proposal-Sharing-service-instances-across-orgs-and-spaces-tp7101.html>
Sent from the CF Dev mailing list archive
<http://cf-dev.70369.x6.nabble.com/> at Nabble.com.


Re: Incubation Proposal: CF Permissions

Scott Truitt <struitt@...>
 

Exciting!

On Thu, Aug 24, 2017 at 12:20 PM Dieu Cao <dcao(a)pivotal.io> wrote:

Super excited to start the process for incubation to the Runtime PMC for
this!
This set of features has long been requested and I'm excited to see
forward progress on it.
Will reach out to you with details on bringing this forth for a vote at
the next Runtime PMC meeting.

-Dieu

Runtime PMC Lead

On Thu, Aug 24, 2017 at 12:09 PM, Christopher Brown <cbrown(a)pivotal.io>
wrote:

Hello,

Pivotal would like to propose to the CF Runtime PMC a new incubation
project, "CF Permissions", focusing on improving the authorization
experience in Cloud Foundry. This project aims to enable granular and more
easily administered authorization for Cloud Foundry.

Project Name: CF Permissions
Project Proposal: https://goo.gl/otZKv6
Proposed Project Lead: Christopher Brown
Development Operating Model: Pairing Model
Initial team committed: 2 engineers from Pivotal

Please let us know if you have any questions.

Thanks,
Christopher Brown, Pivotal


Re: Sample .NET hello_world app

Zach Brown
 

Hey Chris

Noticed the .NET ascii video is up on cloudfoundry.org/platform.
There seems to be a formatting issue with this one too. I think it has to
do with the number of lines in the terminal.
It seems like only 20 lines are being displayed.

The net result is that at the very end, the last couple of lines where it
curls the new endpoint and the result is displayed get completely cut off.

Happy to create another one with different terminal settings if that's the
answer. (My terminal was set to 80x25).



On Mon, Aug 21, 2017 at 9:01 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Zach, thanks again for the .NET video!

Dr. Max, once we have that up, and the Go video fixed, I'll follow up here
with links to all.



On Mon, Aug 21, 2017 at 11:46 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

Graham,

Thanks for catching that, and for your suggestions on the wording above!

-Chris

On Fri, Aug 18, 2017 at 7:43 AM, Graham Bleach <
graham.bleach(a)digital.cabinet-office.gov.uk> wrote:



On 17 August 2017 at 20:58, Chris Clark <cclark(a)cloudfoundry.org> wrote:

A while back I'd asked for help with a few sample apps to go on the CF
website. Thank you to everyone who helped out with that! They are up,
here: https://www.cloudfoundry.org/platform/.
These look pretty good and will be great for showing people how easy it
is to get started.

In the go demo video when the code's being typed into an editor it seems
to have a few linebreaks mid-line-of-code.

I think that the line "deployed in container images on any
infrastructure", would be more correct if it said "deployed in containers
on a choice of cloud infrastructures" - I think "container image" means
something more like a Docker/OCI image than a running container, and there
are *some* restrictions on which IaaS provider it can be deployed on,
although it's a pretty wide choice :)

Other than that, it looks very good.

Cheers,
Graham

--

*Zach Brown* | Strategic Product Owner

650-954-0427 - mobile

zbrown(a)pivotal.io

<http://pivotal.io>


Re: [Proposal] Sharing service instances across orgs and spaces

Mike Youngstrom
 

Great! I just thought of some questions and didn't see them listed in the
thread.

* I assume that the space that originally created the service would be a
kind of "owning" space right? So that space probably wouldn't be able to
delete the service unless it was unbound from other space's apps? Would
the service also need to be unshared before deleted?
* I assume a target space developer can unshare a service shared in their
space but not delete, right?
* Is it possible for a service to opt out or in of being shared perhaps
with a CF specific "requires" service permission? I'm thinking of Vivek
Anand's question about. If on create a service adds a security group to
the space creating it the broker would need to be changed to support
sharing.
* Does a space developer wishing to share a service need to be a space
developer in the space they are sharing into?

Great work keeping this much needed feature moving along!

Mike


On Thu, Aug 24, 2017 at 12:25 PM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Hi all,

I'm pleased to say that work will shortly be starting on the following
sharing service instances workflows:

$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE
$ cf unshare-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE

We will feature flag this work so that this can be enabled or disabled in
a Cloud Foundry deployment. Note that a key change from the workflows we
initially shared is that this feature will now be enabled/disabled for *all
services and service plans in a deployment*. The more explicit *enable-service-sharing
*workflows we initially proposed will likely be developed in a future
version of this feature. This stripped back permissions model will mean
that a Space Developer will be able to share a service instance in their
space into any other org and space.

Please let me know if anyone has any further thoughts on this. Your
feedback is always very much appreciated.

Many thanks,
Matt

On Mon, Jul 10, 2017 at 6:12 AM Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks all for the great feedback. There are a lot of good ideas here
that we will use to help guide the implementation of this.

Gabriel; the relationship service instances have with ASGs is
interesting. I don't think we should automatically modify security groups
when service instances are shared, as there could be security implications
in doing so. But this is definitely something we will look into in detail.

Jouke; permanent migrations of services isn't something we've taken into
account in this sharing proposal, however I can see the use cases. I wonder
if these could be mitigated via another solution to another CF CLI command,
for example, making backing up and restoring data services easier or
available to application developers.

Daniel; I believe that idea has been raised a few times but, as I'm sure
you know, breaking the services layer out of the cloud controller could be
very tricky and time consuming. Zach R would have more thoughts on this I'm
sure.

Dies; we believe enforcing service sharing to be enabled by default is a
more secure approach. I appreciate your point that right now application
developers can effectively workaround this and share services via passing
credentials and using *cf cups*, but we know that some CF users are
looking to hide credentials as best as possible. In a more secure world
where credentials are not visible to application developers and are
protected in something like CredHub, this new workflow would be the only
way to share services, and we'd like to ensure that this new workflow is as
secure as possible.


On Wed, Jul 5, 2017 at 6:37 AM tommyoshields71 <tommyoshields71(a)gmail.com>
wrote:

Tell me is this that expensive coin that I have

On Jul 4, 2017 12:40 AM, "Koper, Dies [via CF Dev]" <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=0>> wrote:

Hi Matt,



Can you explain the background of the service sharing enabling feature?

Who would want to disable this and for what reason?



I can imagine there are services that should not be bound to multiple
apps, maybe because of locking issues.

If that’s not a limitation/feature of the service, it may be a
constraint of the (initial) developer who created this service for a
single-user purpose.

For those cases, I feel it would make sense for the “enable” flag to be
an attribute of the service itself, or of the person (role) creating it.



How does the Org Manager come in play?

Wouldn’t I currently be copying the credentials over to another
org/person (maybe to another app developer) to store in a user-provided
service, so the additional enable step just creates an additional step
offering no protection?



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI




*From:* Matthew McNeeney [mailto:[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7097&i=0>]
*Sent:* Thursday, June 29, 2017 11:36 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <[hidden
email] <http:///user/SendEmail.jtp?type=node&node=7097&i=1>>
*Subject:* [cf-dev] [Proposal] Sharing service instances across orgs
and spaces

Many Cloud Foundry users have expressed a desire to share service
instances across orgs and spaces. Whilst this could be considered an
anti-pattern for some data services, there are many use cases for which the
ability to do this is important. Two examples are sharing config servers
and messaging queues.



The workarounds that exist today (e.g. creating user-provided services)
require credentials to be passed around in some out-of-band way and will
prevent the platform from being able to do things like automatic rotation
of credentials in the future.



We'd like to propose a new workflow that looks like this:



$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE



A SpaceDeveloper in the target org/space will only be able to
bind/unbind to/from the shared service instance, and running cf service
will show that the service instance has been shared.



To manage any security concerns around this, a CF admin would have to
enable one-way sharing between two spaces with a command like:



$ cf enable-service-sharing SERVICE SOURCE_ORG SOURCE_SPACE TARGET_ORG
TARGET_SPACE





We'd love to hear feedback from the community on this proposal. If you
have any other use cases that this could help with, please let us know
about those too.



Matt



------------------------------
If you reply to this email, your message will be added to the
discussion below:
http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-Sharing-
service-instances-across-orgs-and-spaces-tp7076p7097.html
To start a new topic under CF Dev, email [hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=1>
To unsubscribe from CF Dev, click here.
NAML
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
*IMG_20170704_081255.jpg* (1M) Download Attachment
<http://cf-dev.70369.x6.nabble.com/attachment/7101/0/IMG_20170704_081255.jpg>

------------------------------
View this message in context: Re: [cf-dev] Re: [Proposal] Sharing
service instances across orgs and spaces
<http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Re-Proposal-Sharing-service-instances-across-orgs-and-spaces-tp7101.html>
Sent from the CF Dev mailing list archive
<http://cf-dev.70369.x6.nabble.com/> at Nabble.com.


Re: Incubation Proposal: CF Permissions

Dieu Cao <dcao@...>
 

Super excited to start the process for incubation to the Runtime PMC for
this!
This set of features has long been requested and I'm excited to see forward
progress on it.
Will reach out to you with details on bringing this forth for a vote at the
next Runtime PMC meeting.

-Dieu

Runtime PMC Lead

On Thu, Aug 24, 2017 at 12:09 PM, Christopher Brown <cbrown(a)pivotal.io>
wrote:

Hello,

Pivotal would like to propose to the CF Runtime PMC a new incubation
project, "CF Permissions", focusing on improving the authorization
experience in Cloud Foundry. This project aims to enable granular and more
easily administered authorization for Cloud Foundry.

Project Name: CF Permissions
Project Proposal: https://goo.gl/otZKv6
Proposed Project Lead: Christopher Brown
Development Operating Model: Pairing Model
Initial team committed: 2 engineers from Pivotal

Please let us know if you have any questions.

Thanks,
Christopher Brown, Pivotal


Incubation Proposal: CF Permissions

Christopher Brown
 

Hello,

Pivotal would like to propose to the CF Runtime PMC a new incubation
project, "CF Permissions", focusing on improving the authorization
experience in Cloud Foundry. This project aims to enable granular and more
easily administered authorization for Cloud Foundry.

Project Name: CF Permissions
Project Proposal: https://goo.gl/otZKv6
Proposed Project Lead: Christopher Brown
Development Operating Model: Pairing Model
Initial team committed: 2 engineers from Pivotal

Please let us know if you have any questions.

Thanks,
Christopher Brown, Pivotal


Re: [Proposal] Sharing service instances across orgs and spaces

Matt McNeeney
 

Hi all,

I'm pleased to say that work will shortly be starting on the following
sharing service instances workflows:

$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE
$ cf unshare-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE

We will feature flag this work so that this can be enabled or disabled in a
Cloud Foundry deployment. Note that a key change from the workflows we
initially shared is that this feature will now be enabled/disabled for *all
services and service plans in a deployment*. The more explicit
*enable-service-sharing
*workflows we initially proposed will likely be developed in a future
version of this feature. This stripped back permissions model will mean
that a Space Developer will be able to share a service instance in their
space into any other org and space.

Please let me know if anyone has any further thoughts on this. Your
feedback is always very much appreciated.

Many thanks,
Matt

On Mon, Jul 10, 2017 at 6:12 AM Matthew McNeeney <mmcneeney(a)pivotal.io>
wrote:

Thanks all for the great feedback. There are a lot of good ideas here that
we will use to help guide the implementation of this.

Gabriel; the relationship service instances have with ASGs is interesting.
I don't think we should automatically modify security groups when service
instances are shared, as there could be security implications in doing so.
But this is definitely something we will look into in detail.

Jouke; permanent migrations of services isn't something we've taken into
account in this sharing proposal, however I can see the use cases. I wonder
if these could be mitigated via another solution to another CF CLI command,
for example, making backing up and restoring data services easier or
available to application developers.

Daniel; I believe that idea has been raised a few times but, as I'm sure
you know, breaking the services layer out of the cloud controller could be
very tricky and time consuming. Zach R would have more thoughts on this I'm
sure.

Dies; we believe enforcing service sharing to be enabled by default is a
more secure approach. I appreciate your point that right now application
developers can effectively workaround this and share services via passing
credentials and using *cf cups*, but we know that some CF users are
looking to hide credentials as best as possible. In a more secure world
where credentials are not visible to application developers and are
protected in something like CredHub, this new workflow would be the only
way to share services, and we'd like to ensure that this new workflow is as
secure as possible.


On Wed, Jul 5, 2017 at 6:37 AM tommyoshields71 <tommyoshields71(a)gmail.com>
wrote:

Tell me is this that expensive coin that I have

On Jul 4, 2017 12:40 AM, "Koper, Dies [via CF Dev]" <[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=0>> wrote:

Hi Matt,



Can you explain the background of the service sharing enabling feature?

Who would want to disable this and for what reason?



I can imagine there are services that should not be bound to multiple
apps, maybe because of locking issues.

If that’s not a limitation/feature of the service, it may be a
constraint of the (initial) developer who created this service for a
single-user purpose.

For those cases, I feel it would make sense for the “enable” flag to be
an attribute of the service itself, or of the person (role) creating it.



How does the Org Manager come in play?

Wouldn’t I currently be copying the credentials over to another
org/person (maybe to another app developer) to store in a user-provided
service, so the additional enable step just creates an additional step
offering no protection?



Regards,

Dies Koper
Cloud Foundry Product Manager - CLI




*From:* Matthew McNeeney [mailto:[hidden email]
<http:///user/SendEmail.jtp?type=node&node=7097&i=0>]
*Sent:* Thursday, June 29, 2017 11:36 PM
*To:* Discussions about Cloud Foundry projects and the system overall. <[hidden
email] <http:///user/SendEmail.jtp?type=node&node=7097&i=1>>
*Subject:* [cf-dev] [Proposal] Sharing service instances across orgs
and spaces

Many Cloud Foundry users have expressed a desire to share service
instances across orgs and spaces. Whilst this could be considered an
anti-pattern for some data services, there are many use cases for which the
ability to do this is important. Two examples are sharing config servers
and messaging queues.



The workarounds that exist today (e.g. creating user-provided services)
require credentials to be passed around in some out-of-band way and will
prevent the platform from being able to do things like automatic rotation
of credentials in the future.



We'd like to propose a new workflow that looks like this:



$ cf share-service SERVICE_INSTANCE TARGET_ORG TARGET_SPACE



A SpaceDeveloper in the target org/space will only be able to
bind/unbind to/from the shared service instance, and running cf service
will show that the service instance has been shared.



To manage any security concerns around this, a CF admin would have to
enable one-way sharing between two spaces with a command like:



$ cf enable-service-sharing SERVICE SOURCE_ORG SOURCE_SPACE TARGET_ORG
TARGET_SPACE





We'd love to hear feedback from the community on this proposal. If you
have any other use cases that this could help with, please let us know
about those too.



Matt



------------------------------
If you reply to this email, your message will be added to the discussion
below:

http://cf-dev.70369.x6.nabble.com/cf-dev-Proposal-Sharing-service-instances-across-orgs-and-spaces-tp7076p7097.html
To start a new topic under CF Dev, email [hidden email]
<http:///user/SendEmail.jtp?type=node&node=7101&i=1>
To unsubscribe from CF Dev, click here.
NAML
<http://cf-dev.70369.x6.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
*IMG_20170704_081255.jpg* (1M) Download Attachment
<http://cf-dev.70369.x6.nabble.com/attachment/7101/0/IMG_20170704_081255.jpg>

------------------------------
View this message in context: Re: [cf-dev] Re: [Proposal] Sharing
service instances across orgs and spaces
<http://cf-dev.70369.x6.nabble.com/Re-cf-dev-Re-Proposal-Sharing-service-instances-across-orgs-and-spaces-tp7101.html>
Sent from the CF Dev mailing list archive
<http://cf-dev.70369.x6.nabble.com/> at Nabble.com.


CF disable-service-access broken

Kamath, Prasad
 

Hello ,

We have observed that the working on cf disable-service-access is broken with the latest CF release . we are on release no: 271

Below are the details of the issue :



1. cf enable-service-access redis -p v3.0-container



1. cf service-access -b service-fabrik-broker -e redis

i336605:vcap(a)AWS:HCP-STAGING:~$ cf service-access -b service-fabrik-broker -e redis
Getting service access for broker service-fabrik-broker and service redis as admin...
broker: service-fabrik-broker
service plan access orgs
redis v3.0-container all
redis v3.0-container-large all


1. cf disable-service-access redis -p v3.0-container -o test


1. cf service-access -b service-fabrik-broker -e redis


Getting service access for broker service-fabrik-broker and service redis as admin...
broker: service-fabrik-broker
service plan access orgs
redis v3.0-container all
redis v3.0-container-large all


As you can see above even after step 3 , the output of step 4 shows that the service plan is enabled for all Orgs . Has anyone encountered this issue ?

Let me know if you need any more details .

Regards,
Prasad


Uncle Sam wants YOU... to work on Cloud Foundry (and other stuff) on the public dime!

Bret Mogilefsky
 

[I have no idea if there's an existing protocol for posting messages like this. If so, I apologize! Please redirect me to the right place and feel free to nuke this message from the list archives.]

We’ve got multiple Consulting Software Engineer positions open at 18F (https://18f.gsa.gov). Come work on cool stuff and make a major impact by improving the services the US federal government provides to the public! 🇺🇸

There's a high probability you'd end up working on the team that makes https://cloud.gov, GSA's compliance-focused deployment of OSS Cloud Foundry. We're a great team that maintains tons of Cloud Foundry-related repos (https://cloud.gov/docs/ops/repos/) and makes tons of upstream PRs to the community. ;)

Remote-friendly. Applications close 9/1…
Details at https://18f.gsa.gov/join/
DM @jacobian on Twitter if you have specific questions about these roles.

Regards,
Bret Mogilefsky
product lead on cloud.gov at GSA/FAS/TTS/18F


Re: CF Marketplace: Forms Due Sept. 5

Chip Childers <cchilders@...>
 

Namespace collisions FTW!

The "Marketplace" within the platform is what we all know and love (service
brokers expose stuff, CF admins make available to devs, devs consume).

What the email below is about is not a platform thing... it's an ecosystem
thing. Think training services, IaaS providers, and yes... including
commercial products / services with service broker APIs.

On Wed, Aug 23, 2017 at 5:29 PM Jane Day <jday(a)pivotal.io> wrote:

Hello Chip,
How does this new "marketplace" relate to the current marketplace,
described here:
https://docs.cloudfoundry.org/devguide/services/ ?
TIA,
jane

On Wed, Aug 23, 2017 at 1:39 PM, Chip Childers <cchilders(a)cloudfoundry.org
wrote:
This isn't CF development or usage related, but it may be relevant to
many of you. Apologies for hitting your inbox if it isn't.

The CFF team is building a "marketplace".. (basically an online directory
of services / products tied to CF) and want to hear about your company's
offerings. The goal is to help highlight the awesome ecosystem around Cloud
Foundry.

See below for details.

---------- Forwarded message ---------
From: Melissa Logan <mlogan(a)cloudfoundry.org>
Date: Wed, Aug 23, 2017 at 1:30 PM
Subject: CF Marketplace: Forms Due Sept. 5
To: Marketing Workgroup <marketing-workgroup(a)cloudfoundry.org>
Cc: Foundation Staff <foundation-staff(a)cloudfoundry.org>


MWG Members:

As stated in our 2017 marketing plan, the Foundation is creating a
marketplace on CloudFoundry.org to showcase the depth of the Cloud Foundry
ecosystem. For those just getting started, or who want to expand their use
of the platform, it will be a comprehensive directory of available
solutions and services.

Our site is on track to reach 2M pageviews this year - almost double YOY
and averaging 166K views per month - and we continue to make site/content
improvements. We are planning a big promo push for the marketplace starting
at Europe Summit, however, *we need your input for this to be successful*
.

Clicking on links below will take you to a short form. Please complete
one for each product/service offering. *To be included in the big push,
forms are due by Wed, Sept. 6. *It should only take a few minutes per
form.

Categories:

- *Training <https://cloudfoundry.typeform.com/to/DmwLdr> - *Authorized
and non-authorized training partners.
- *Distributions <https://cloudfoundry.typeform.com/to/WEGhti> *-
Certified and non-certified providers. If your info is here
<https://www.cloudfoundry.org/certified-platforms/>, no need to
complete form unless you have updates.
- *Infrastructure Providers
<https://cloudfoundry.typeform.com/to/nAymGJ>* - IaaS or
infrastructure providers supported by CF BOSH CPI.
- *Services <https://cloudfoundry.typeform.com/to/xLVFLR>* -
Implementations of the Open Service Broker API designed to work with Cloud
Foundry (e.g. service integrations, buildpack extensions).
- *Consulting & Integrators
<https://cloudfoundry.typeform.com/to/nljxqs> *- With specific
practices that include Cloud Foundry. If you offer training, complete that
form separately.
- *Other Integrations <https://cloudfoundry.typeform.com/to/uxDtFo> *-
Other integrations that work with Cloud Foundry not described above.

In the coming weeks, we'll share page design.

Let us know if you have questions in the meantime.

Thanks in advance!

Melissa



--
Melissa Logan
Cloud Foundry Foundation

Do you spend more time on operations than coding? Maybe it's time to get
Cloud Foundry. https://youtu.be/em-W0rVbCLc

--
You received this message because you are subscribed to the Google Groups
"Foundation Staff" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foundation-staff+unsubscribe(a)cloudfoundry.org.
To post to this group, send email to foundation-staff(a)cloudfoundry.org.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/foundation-staff/CANuAHwoydN_-pbhwtFm32paE9yuDgJiD7_qbAe1gq-GOhCmW0w%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/foundation-staff/CANuAHwoydN_-pbhwtFm32paE9yuDgJiD7_qbAe1gq-GOhCmW0w%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: CF Marketplace: Forms Due Sept. 5

Jane Day
 

Hello Chip,
How does this new "marketplace" relate to the current marketplace,
described here:
https://docs.cloudfoundry.org/devguide/services/ ?
TIA,
jane

On Wed, Aug 23, 2017 at 1:39 PM, Chip Childers <cchilders(a)cloudfoundry.org>
wrote:

This isn't CF development or usage related, but it may be relevant to many
of you. Apologies for hitting your inbox if it isn't.

The CFF team is building a "marketplace".. (basically an online directory
of services / products tied to CF) and want to hear about your company's
offerings. The goal is to help highlight the awesome ecosystem around Cloud
Foundry.

See below for details.

---------- Forwarded message ---------
From: Melissa Logan <mlogan(a)cloudfoundry.org>
Date: Wed, Aug 23, 2017 at 1:30 PM
Subject: CF Marketplace: Forms Due Sept. 5
To: Marketing Workgroup <marketing-workgroup(a)cloudfoundry.org>
Cc: Foundation Staff <foundation-staff(a)cloudfoundry.org>


MWG Members:

As stated in our 2017 marketing plan, the Foundation is creating a
marketplace on CloudFoundry.org to showcase the depth of the Cloud Foundry
ecosystem. For those just getting started, or who want to expand their use
of the platform, it will be a comprehensive directory of available
solutions and services.

Our site is on track to reach 2M pageviews this year - almost double YOY
and averaging 166K views per month - and we continue to make site/content
improvements. We are planning a big promo push for the marketplace starting
at Europe Summit, however, *we need your input for this to be successful*
.

Clicking on links below will take you to a short form. Please complete one
for each product/service offering. *To be included in the big push, forms
are due by Wed, Sept. 6. *It should only take a few minutes per form.

Categories:

- *Training <https://cloudfoundry.typeform.com/to/DmwLdr> - *Authorized
and non-authorized training partners.
- *Distributions <https://cloudfoundry.typeform.com/to/WEGhti> *-
Certified and non-certified providers. If your info is here
<https://www.cloudfoundry.org/certified-platforms/>, no need to
complete form unless you have updates.
- *Infrastructure Providers
<https://cloudfoundry.typeform.com/to/nAymGJ>* - IaaS or
infrastructure providers supported by CF BOSH CPI.
- *Services <https://cloudfoundry.typeform.com/to/xLVFLR>* -
Implementations of the Open Service Broker API designed to work with Cloud
Foundry (e.g. service integrations, buildpack extensions).
- *Consulting & Integrators
<https://cloudfoundry.typeform.com/to/nljxqs> *- With specific
practices that include Cloud Foundry. If you offer training, complete that
form separately.
- *Other Integrations <https://cloudfoundry.typeform.com/to/uxDtFo> *-
Other integrations that work with Cloud Foundry not described above.

In the coming weeks, we'll share page design.

Let us know if you have questions in the meantime.

Thanks in advance!

Melissa



--
Melissa Logan
Cloud Foundry Foundation

Do you spend more time on operations than coding? Maybe it's time to get
Cloud Foundry. https://youtu.be/em-W0rVbCLc

--
You received this message because you are subscribed to the Google Groups
"Foundation Staff" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foundation-staff+unsubscribe(a)cloudfoundry.org.
To post to this group, send email to foundation-staff(a)cloudfoundry.org.
To view this discussion on the web visit https://groups.google.com/a/
cloudfoundry.org/d/msgid/foundation-staff/CANuAHwoydN_-
pbhwtFm32paE9yuDgJiD7_qbAe1gq-GOhCmW0w%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/foundation-staff/CANuAHwoydN_-pbhwtFm32paE9yuDgJiD7_qbAe1gq-GOhCmW0w%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815 <(267)%20250-0815>


CF Marketplace: Forms Due Sept. 5

Chip Childers <cchilders@...>
 

This isn't CF development or usage related, but it may be relevant to many
of you. Apologies for hitting your inbox if it isn't.

The CFF team is building a "marketplace".. (basically an online directory
of services / products tied to CF) and want to hear about your company's
offerings. The goal is to help highlight the awesome ecosystem around Cloud
Foundry.

See below for details.

---------- Forwarded message ---------
From: Melissa Logan <mlogan(a)cloudfoundry.org>
Date: Wed, Aug 23, 2017 at 1:30 PM
Subject: CF Marketplace: Forms Due Sept. 5
To: Marketing Workgroup <marketing-workgroup(a)cloudfoundry.org>
Cc: Foundation Staff <foundation-staff(a)cloudfoundry.org>


MWG Members:

As stated in our 2017 marketing plan, the Foundation is creating a
marketplace on CloudFoundry.org to showcase the depth of the Cloud Foundry
ecosystem. For those just getting started, or who want to expand their use
of the platform, it will be a comprehensive directory of available
solutions and services.

Our site is on track to reach 2M pageviews this year - almost double YOY
and averaging 166K views per month - and we continue to make site/content
improvements. We are planning a big promo push for the marketplace starting
at Europe Summit, however, *we need your input for this to be successful*.

Clicking on links below will take you to a short form. Please complete one
for each product/service offering. *To be included in the big push, forms
are due by Wed, Sept. 6. *It should only take a few minutes per form.

Categories:

- *Training <https://cloudfoundry.typeform.com/to/DmwLdr> - *Authorized
and non-authorized training partners.
- *Distributions <https://cloudfoundry.typeform.com/to/WEGhti> *-
Certified and non-certified providers. If your info is here
<https://www.cloudfoundry.org/certified-platforms/>, no need to complete
form unless you have updates.
- *Infrastructure Providers
<https://cloudfoundry.typeform.com/to/nAymGJ>* - IaaS or infrastructure
providers supported by CF BOSH CPI.
- *Services <https://cloudfoundry.typeform.com/to/xLVFLR>* -
Implementations of the Open Service Broker API designed to work with Cloud
Foundry (e.g. service integrations, buildpack extensions).
- *Consulting & Integrators
<https://cloudfoundry.typeform.com/to/nljxqs> *- With specific practices
that include Cloud Foundry. If you offer training, complete that form
separately.
- *Other Integrations <https://cloudfoundry.typeform.com/to/uxDtFo> *-
Other integrations that work with Cloud Foundry not described above.

In the coming weeks, we'll share page design.

Let us know if you have questions in the meantime.

Thanks in advance!

Melissa



--
Melissa Logan
Cloud Foundry Foundation

Do you spend more time on operations than coding? Maybe it's time to get
Cloud Foundry. https://youtu.be/em-W0rVbCLc

--
You received this message because you are subscribed to the Google Groups
"Foundation Staff" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to foundation-staff+unsubscribe(a)cloudfoundry.org.
To post to this group, send email to foundation-staff(a)cloudfoundry.org.
To view this discussion on the web visit
https://groups.google.com/a/cloudfoundry.org/d/msgid/foundation-staff/CANuAHwoydN_-pbhwtFm32paE9yuDgJiD7_qbAe1gq-GOhCmW0w%40mail.gmail.com
<https://groups.google.com/a/cloudfoundry.org/d/msgid/foundation-staff/CANuAHwoydN_-pbhwtFm32paE9yuDgJiD7_qbAe1gq-GOhCmW0w%40mail.gmail.com?utm_medium=email&utm_source=footer>
.
--
Chip Childers
CTO, Cloud Foundry Foundation
1.267.250.0815


Re: Issue with cf service plan name access and update

Ketaki Gadre <kets.gadre@...>
 

Hi Zach,

We are already using cf release greater than 255, I still see the same
issue. Any idea why this should be happening?

On Tue, Jul 18, 2017 at 4:22 AM, Zach Robinson <zrobinson(a)pivotal.io> wrote:

Hello Ketaki,

This is a known issue. When a plan is disabled it becomes "invisible" to
users. However, we don't remove existing service instances because this
would break existing apps. Ideally a user would then update to a new plan
that is supported by their marketplace. However, as you noted, the update
doesn't work because the user can no longer see the old plan.

We addressed this in this story https://www.pivotaltracker.
com/story/show/137123835 and the fix should be available in cf release
255 or greater.

-Zach


Re: Angular 2 app on cloud foundry

Daniel Jones
 

Hi Wenqun,

I'm not much of a front-end person. How do you define "dynamic" in this
sense? I've seen the term used in Angular projects to refer to deciding
which modules loaded in at run-time, which wouldn't be a problem with the
staticfile buildpack as it's all client-side logic.

If you need to dynamically generate the content of JavaScript files that
are then served to the client, you will need some sort of server-side
processing capability. If you want to keep everything JavaScript, then you
could use the Node buildpack.

Regards,
Daniel Jones - CTO
+44 (0)79 8000 9153
@DanielJonesEB <https://twitter.com/DanielJonesEB>
*EngineerBetter* Ltd <http://www.engineerbetter.com> - UK Cloud Foundry
Specialists

On 22 August 2017 at 21:55, Lang, Wenqun [USA] <Lang_Wenqun(a)bah.com> wrote:

Hello,



Is there a way to deploy a full fledged dynamic angular2 application in
CloudFoundry? There is a staticfile buildpack, I assume it won’t support
dynamic content.



Looking forward hearing back from you.



Thanks,

Wenqun Lang


Re: AWS Elastic Cache service broker

Dave Nielsen <dnielsen@...>
 

Hi Sachin,

It may not support Elastic Cache, but there is a Redis Service Broker
<https://docs.pivotal.io/partners/rle-service-broker/> for Pivotal
Labs that works with Redis Enterprise
<https://redislabs.com/why-redis/redis-enterprise/> by Redis Labs. You can
use it in any situation where you are considering Elastic Cache, plus a lot
lot more.

There is also an open source version of it on Github
<https://github.com/RedisLabs/cf-redislabs-broker>. This was the original
version, before they turned it into a Pivotal Tile.

A bit late, but I answered it within 5 mins of reading it = )

Dave Nielsen @davenielsen
Big Data Technologies, Intel Software
Organizer: http://meetup.com/cloudfoundry

On Fri, Jan 22, 2016 at 9:46 AM, Sachin Garg <satch326(a)gmail.com> wrote:

Is there an Elastic Cache service broker for AWS that can be leveraged?

Thanks,
Sachin
--
Dave Nielsen
Technical Program Manager, BigDL, Deep Learning for Spark
Big Data Technologies, Intel Software
Organizer: SVBigData, <http://svbigdata.com/>SVDevOps, CloudCamp
twitter davenielsen <http://twitter.com/davenielsen>; linkedin dnielsen
<http://linkedin.com/in/dnielsen>; fb: dcnielsen <http://fb.com/dcnielsen>
skype: davenielsen; gtalk: dnielsen; mobile: 415-531-6674


Angular 2 app on cloud foundry

Lang, Wenqun [USA] <Lang_Wenqun@...>
 

Hello,

Is there a way to deploy a full fledged dynamic angular2 application in CloudFoundry? There is a staticfile buildpack, I assume it won't support dynamic content.

Looking forward hearing back from you.

Thanks,
Wenqun Lang


Re: HTTP tracing on internal CF components?

Behrooz Nobakht <nobeh5@...>
 

On Tue, Aug 22, 2017 at 10:37 PM, Behrooz Nobakht <nobeh5(a)gmail.com> wrote:

Hi,

CF docs [1], [2] explain how HTTP tracing with Zipkin can be enabled
and how gorouter intercepts the HTTP headers.

Is there also a way other internal components similarly trace their
requests and
send the traces to a Zipkin server (or even log)? Motivation is mainly to
try identify bottlenecks in a CF deployment to extract improvement actions.

Behrooz

--
-- Behrooz Nobakht


HTTP tracing on internal CF components?

Behrooz Nobakht <nobeh5@...>
 

Hi,

CF docs [1], [2] explain how HTTP tracing with Zipkin can be enabled
and how gorouter intercepts the HTTP headers.

Is there also a way other internal components similarly trace their
requests and
send the traces to a Zipkin server (or even log)? Motivation is mainly to
try identify bottlenecks in a CF deployment to extract improvement actions.

Behrooz

2201 - 2220 of 9389