Date   

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

Mike Youngstrom
 


Regarding the unsharing workflow, the app developers we've spoken to
suggested that they would be frustrated if they were not able to unshare or
delete a service instance that they had created. When deleting a service
instance that has bindings in the same space, the *delete-service *command
fails and shows an error stating the service instance has bindings. A
developer can then, if they want to, unbind any applications and then retry
the delete i.e. they are enabled to delete the service instance at any
time; they may just have to run some other commands first. When the service
instance has bindings from another space, that they may or may not have
access to, we'd like to still fully empower developers in the 'owning'
space, and ensure they are never blocked by having to run a command in a
space that they cannot access. (This same logic would apply for deleting a
service instance that has bindings in a shared space).

Does that logic make sense? What are your thoughts on this?
I think the logic of auto-unbinding the service makes sense as long as the
user doing the delete has a way to know that other applications
(potentially in other spaces) are bound to the service and acknowledge that
they wanted to unbind and delete anyway. However, to help even out the
workflow for both shared and unshared services I would recommend having the
CLI team look into changing the current behavior for local service
bindings to match that of shared service binding. That change would be, if
I attempt to delete a service that has local and/or shared service bindings
then the user should be notified of those bindings and confirm the desire
to unbind and delete the service instance anyway.

All that above assumes all unbind requests succeed. Today if an unbind
fails for a local service bound to a local application then the user is
unable to delete that service until the unbind can succeed or they ask an
administrator to "purge" the service instance. I think the behavior should
be the same for a shared service instance binding. If a shared unbind
fails then the service should not be allowed to be deleted until that
unbind succeeds. Unless an administrator purges the service instance.

Thoughts?

Mike


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

Matt McNeeney
 

Hey Mike,

Regarding the unsharing workflow, the app developers we've spoken to
suggested that they would be frustrated if they were not able to unshare or
delete a service instance that they had created. When deleting a service
instance that has bindings in the same space, the *delete-service *command
fails and shows an error stating the service instance has bindings. A
developer can then, if they want to, unbind any applications and then retry
the delete i.e. they are enabled to delete the service instance at any
time; they may just have to run some other commands first. When the service
instance has bindings from another space, that they may or may not have
access to, we'd like to still fully empower developers in the 'owning'
space, and ensure they are never blocked by having to run a command in a
space that they cannot access. (This same logic would apply for deleting a
service instance that has bindings in a shared space).

Does that logic make sense? What are your thoughts on this?

Regarding the org manager deleting a space, I agree that this will remove
any shared services that have been shared *into *that space. I'll
investigate what this workflow could look like for a developer who wants to
remove a service instance that has been shared with them, as I agree this
sounds like a sensible workflow.

Hope this helps. Keep the feedback coming!

On Mon, Aug 28, 2017 at 4:57 PM Mike Youngstrom <youngm(a)gmail.com> wrote:

Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!
Thanks Matt. It also helps to know that bind will include space and org
guid. Any thoughts on my other comments? For your convenience I've pasted
them below.

Mike


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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?


doppler client firehose subscribe turned disposabed

SOHN SEOROCK
 

I'm testing cloudfoundry doppler client using cf-cf-java

i'm using firehose subscribe to receive data from cloud foundry and
receive well data a few minute, but few minutes later firehose do not
receive data.

so i checked the debug log and i detected sometihg
receive websocket frame opCode=2, when program receive data well
but receive websocket frame opCode=8, then can not receive data
also, reactor.ipc.netty.http.client.HttpClient logged in order
FLUSH
CLOSE
INACTIVE

what should i do to receive data without stopping

thanks.


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

Mike Youngstrom
 


Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!
Thanks Matt. It also helps to know that bind will include space and org
guid. Any thoughts on my other comments? For your convenience I've pasted
them below.

Mike


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.
Interesting. That behavior is different for bindings in the owning space.
Today if a space developer wishes to delete a service in its owning space,
that is bound to applications, the operation will fail until that service
is unbound. I wonder if the CAPI or CLI team would consider changing that
behavior so that the functionality is equivalent between shared and not
shared services?

If the space developer in the owning space attempts to delete a service and
the unbind fails in a shared space then I assume the delete service request
will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?


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

Guillaume Berche
 

Mike:

If this service were to be shared I would need to instead listen on bind
get the application the service is being bound to and add an ASG to that
space. Then on unbind I'd need to see if all the applications in the space
with the binding are unbound from the service and remove the ASG or to
cleanup I'd need to continually scan the CC to see if there are any spaces
with this ASG without an instance of the service and clean it up. Not
impossible but a pain for a service that I might not be worth the effort
enable sharing on.

this is what we have implemented into sec-group-broker-filter[0]

Matt:

Some feedback: this feature seems pretty useful to us. We'll have to make
some adaptations to our broker before enabling it:

The current service plan visibility feature [1] would be affected by CF
instances that enable the service sharing feature. Up to now, admins were
controlling visibility of service plans (when disabling the space-scoped
service broker flag). With the service sharing feature turned on, a space
developper granted visibility into a service plan will be able to
transitively share it with other orgs.

We have multiple use-cases for the service plan visibility feature at
orange:
a- restrict service offering whose service instances imply large/costly
amount of resources.
b- restrict service offering whose service instances provide access to
confidential data. For example, a vault service offering for org1 should
not be shared to org2.
c- restrict service offerings to apply corporate security policies. For
example, orgs that have access to public internet domains for inbound
traffic are not granted outbound intranet access through the associated
service plan not being visible in these orgs

Service instance sharing is fine for a), but more problematic for b) or c).

However, most of our service brokers are proxied with our
sec-group-broker-filter [0] which could be enhanced to opt-out service
instances shared among orgs [3]. So our admins should be able to enable the
service sharing flag, and still be able to reject binding of shared service
instances on some service plans.

And some questions:

Q1: Would the service instance feature also enable sharing of service
instances instanciated from space-scoped service brokers ?

Q2: Is it planned that specific audit events be available in both the
originating and target spaces as to be able to trace the "actor" of the
sharing/unsharing/create-binding/delete-binding operations ?

Q3: Is is planned that space developers listing service instances in their
space will be able to clearly identify the ones they own from the ones that
are shared to them ?

If not, one could also imagine an edge case, where a malicious space
developer who gained a list of org/spaces of a public CF instance would try
to perform some phishing on target orgs/spaces by sharing a malicious route
service instance (possibly named close to a common service such as "akamai"
or "cloudflare"), and hope to sniff some app traffic.

[0] https://github.com/orange-cloudfoundry/sec-group-broker-filter
[1] http://docs.cloudfoundry.org/services/access-control.html
[2] http://docs.cloudfoundry.org/services/managing-service-brokers.html
[3] https://github.com/orange-cloudfoundry/sec-group-broker-filter/issues/49

Thanks,

Guillaume.

On Mon, Aug 28, 2017 at 11:39 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

Peter: The org and space GUIDs will be sent to brokers in the bind request
using the same context object that is sent when provisioning a service
instance (this work is underway now). Good spot though!

Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!


On Mon, 28 Aug 2017 at 07:27, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi,

So far it was safe to assume that a service instance and bound
applications are in the same space. If a service instance is shared across
args/spaces, this is no longer true.
Currently a service broker does not receive *organization_guid* and
*space_guid* in Bind
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#binding>
operation. It receives only the *app_guid*. CC sends *organizarion_guid*
and *space_guid* only in Provision
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#provisioning>
operation.
So, unless the service broker API is extended, there will be no easy way
for the broker to get this data.

Best regards,
Petar


On Mon, Aug 28, 2017 at 12:19 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

That said, this isn't a big deal. if it were a difficult thing for the
platform to allow a broker to opt out of sharing then I would say forget
about it. I'm only thinking that since the platform already has a
mechanism seemingly purpose built for this type of scenario (requires
permissions) why not be on the safe side and take the simple step of
utilizing that solution to help alleviate the issues this feature may
present to a small number of brokers?

Again, if adding a simple broker permission introduces some complexity
I'm not seeing then go ahead and drop the whole idea. I don't want this
feedback to derail the momentum in place to get shared services
implemented. This is too important of a feature to have delayed because of
feedback as minor as this.

Mike

On Sun, Aug 27, 2017 at 3:07 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


Could you share more on the service you have developed that will not
work if bound to from another org/space?

What extra information would it need to function correctly?
Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some
cases wouldn't be pretty. For example, I have a broker that today on
provision grants an ASG to the space the service is provisioned and removes
the ASG on deprovision. If this service were to be shared I would need to
instead listen on bind get the application the service is being bound to
and add an ASG to that space. Then on unbind I'd need to see if all the
applications in the space with the binding are unbound from the service and
remove the ASG or to cleanup I'd need to continually scan the CC to see if
there are any spaces with this ASG without an instance of the service and
clean it up. Not impossible but a pain for a service that I might not be
worth the effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has
had in the past. We've considered using unbindable services as a way to
add meta data like billing or CI information to a space. This might not be
a service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC.
These brokers might utilize the space guid in some way such as ensuring the
space is authorized to create instances of this service in some billing
system, for example, because this service hasn't been trusted with admin
access to the CC it would have no way to know that another space is also
using the service. This information might be significant to the billing
model of the service.

Adding service broker lifecycle events to notify a broker of sharing
and unsharing might help these types of use cases to be handled by a
broker. But, I think that would not be something prudent to attempt to
tackled for this initial release.

Since the service broker api is one of the few open/stable extension
points on the cloud controller you might be surprised at some of the the
odd things customers have done with custom service brokers. It seems to me
that instead of requiring all services to support sharing it would be
prudent to allow services to opt out (or in) to this new feature.

Thanks,
Mike




On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a
service and the unbind fails in a shared space then I assume the delete
service request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in
it wishes to delete the space a service is shared in, then I assume that
would succeed without the owning space developer first unsharing the
service correct? If so it seems kind of strange they can unshare the
service by deleting the space but not by simply unsharing it individually.
Why not let the space developer of a space a service is shared into let
that space developer unshare the service? Is there some hidden complexity
I'm missing?

* 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.
IMO as a broker developer of services that will not function if
shared, I would really like a permission for the broker to opt in/out of
services of it's type being shared. I'd hate for my users to start sharing
services that don't support sharing and then be confused as to why the
shared service doesn't work. Granted I know there is the global flag that
can turn it all off. But, I have some services that may technically never
be able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/
servicebroker/blob/v2.12/spec.md#catalog-management) is too much to
ask. Unless there is some complexity I'm not seeing?


Thanks,
Mike


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

Matt McNeeney
 

Peter: The org and space GUIDs will be sent to brokers in the bind request
using the same context object that is sent when provisioning a service
instance (this work is underway now). Good spot though!

Mike: Thanks for explaining how your brokers would need modifications for
sharing to work as desired. I'll investigate how we can allow brokers to
explicitly opt in to sharing (either via the requires field or some other
mechanism). I'll also look into a workflow where a space developer who has
an instance shared into their space can trigger an I share/remove. Thanks
for the great feedback!

On Mon, 28 Aug 2017 at 07:27, Peter Dotchev <dotchev(a)gmail.com> wrote:

Hi,

So far it was safe to assume that a service instance and bound
applications are in the same space. If a service instance is shared across
args/spaces, this is no longer true.
Currently a service broker does not receive *organization_guid* and
*space_guid* in Bind
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#binding>
operation. It receives only the *app_guid*. CC sends *organizarion_guid*
and *space_guid* only in Provision
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#provisioning>
operation.
So, unless the service broker API is extended, there will be no easy way
for the broker to get this data.

Best regards,
Petar


On Mon, Aug 28, 2017 at 12:19 AM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

That said, this isn't a big deal. if it were a difficult thing for the
platform to allow a broker to opt out of sharing then I would say forget
about it. I'm only thinking that since the platform already has a
mechanism seemingly purpose built for this type of scenario (requires
permissions) why not be on the safe side and take the simple step of
utilizing that solution to help alleviate the issues this feature may
present to a small number of brokers?

Again, if adding a simple broker permission introduces some complexity
I'm not seeing then go ahead and drop the whole idea. I don't want this
feedback to derail the momentum in place to get shared services
implemented. This is too important of a feature to have delayed because of
feedback as minor as this.

Mike

On Sun, Aug 27, 2017 at 3:07 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


Could you share more on the service you have developed that will not
work if bound to from another org/space?

What extra information would it need to function correctly?
Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some
cases wouldn't be pretty. For example, I have a broker that today on
provision grants an ASG to the space the service is provisioned and removes
the ASG on deprovision. If this service were to be shared I would need to
instead listen on bind get the application the service is being bound to
and add an ASG to that space. Then on unbind I'd need to see if all the
applications in the space with the binding are unbound from the service and
remove the ASG or to cleanup I'd need to continually scan the CC to see if
there are any spaces with this ASG without an instance of the service and
clean it up. Not impossible but a pain for a service that I might not be
worth the effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has
had in the past. We've considered using unbindable services as a way to
add meta data like billing or CI information to a space. This might not be
a service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC.
These brokers might utilize the space guid in some way such as ensuring the
space is authorized to create instances of this service in some billing
system, for example, because this service hasn't been trusted with admin
access to the CC it would have no way to know that another space is also
using the service. This information might be significant to the billing
model of the service.

Adding service broker lifecycle events to notify a broker of sharing and
unsharing might help these types of use cases to be handled by a broker.
But, I think that would not be something prudent to attempt to tackled for
this initial release.

Since the service broker api is one of the few open/stable extension
points on the cloud controller you might be surprised at some of the the
odd things customers have done with custom service brokers. It seems to me
that instead of requiring all services to support sharing it would be
prudent to allow services to opt out (or in) to this new feature.

Thanks,
Mike




On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a
service and the unbind fails in a shared space then I assume the delete
service request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in
it wishes to delete the space a service is shared in, then I assume that
would succeed without the owning space developer first unsharing the
service correct? If so it seems kind of strange they can unshare the
service by deleting the space but not by simply unsharing it individually.
Why not let the space developer of a space a service is shared into let
that space developer unshare the service? Is there some hidden complexity
I'm missing?

* 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.
IMO as a broker developer of services that will not function if
shared, I would really like a permission for the broker to opt in/out of
services of it's type being shared. I'd hate for my users to start sharing
services that don't support sharing and then be confused as to why the
shared service doesn't work. Granted I know there is the global flag that
can turn it all off. But, I have some services that may technically never
be able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#catalog-management) is
too much to ask. Unless there is some complexity I'm not seeing?


Thanks,
Mike


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

Peter Dotchev <dotchev@...>
 

Hi,

So far it was safe to assume that a service instance and bound applications
are in the same space. If a service instance is shared across args/spaces,
this is no longer true.
Currently a service broker does not receive *organization_guid* and
*space_guid* in Bind
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#binding>
operation. It receives only the *app_guid*. CC sends *organizarion_guid*
and *space_guid* only in Provision
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#provisioning>
operation.
So, unless the service broker API is extended, there will be no easy way
for the broker to get this data.

Best regards,
Petar

On Mon, Aug 28, 2017 at 12:19 AM, Mike Youngstrom <youngm(a)gmail.com> wrote:

That said, this isn't a big deal. if it were a difficult thing for the
platform to allow a broker to opt out of sharing then I would say forget
about it. I'm only thinking that since the platform already has a
mechanism seemingly purpose built for this type of scenario (requires
permissions) why not be on the safe side and take the simple step of
utilizing that solution to help alleviate the issues this feature may
present to a small number of brokers?

Again, if adding a simple broker permission introduces some complexity I'm
not seeing then go ahead and drop the whole idea. I don't want this
feedback to derail the momentum in place to get shared services
implemented. This is too important of a feature to have delayed because of
feedback as minor as this.

Mike

On Sun, Aug 27, 2017 at 3:07 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:


Could you share more on the service you have developed that will not
work if bound to from another org/space?

What extra information would it need to function correctly?
Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some
cases wouldn't be pretty. For example, I have a broker that today on
provision grants an ASG to the space the service is provisioned and removes
the ASG on deprovision. If this service were to be shared I would need to
instead listen on bind get the application the service is being bound to
and add an ASG to that space. Then on unbind I'd need to see if all the
applications in the space with the binding are unbound from the service and
remove the ASG or to cleanup I'd need to continually scan the CC to see if
there are any spaces with this ASG without an instance of the service and
clean it up. Not impossible but a pain for a service that I might not be
worth the effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has had
in the past. We've considered using unbindable services as a way to add
meta data like billing or CI information to a space. This might not be a
service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC.
These brokers might utilize the space guid in some way such as ensuring the
space is authorized to create instances of this service in some billing
system, for example, because this service hasn't been trusted with admin
access to the CC it would have no way to know that another space is also
using the service. This information might be significant to the billing
model of the service.

Adding service broker lifecycle events to notify a broker of sharing and
unsharing might help these types of use cases to be handled by a broker.
But, I think that would not be something prudent to attempt to tackled for
this initial release.

Since the service broker api is one of the few open/stable extension
points on the cloud controller you might be surprised at some of the the
odd things customers have done with custom service brokers. It seems to me
that instead of requiring all services to support sharing it would be
prudent to allow services to opt out (or in) to this new feature.

Thanks,
Mike




On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in
it wishes to delete the space a service is shared in, then I assume that
would succeed without the owning space developer first unsharing the
service correct? If so it seems kind of strange they can unshare the
service by deleting the space but not by simply unsharing it individually.
Why not let the space developer of a space a service is shared into let
that space developer unshare the service? Is there some hidden complexity
I'm missing?

* 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.
IMO as a broker developer of services that will not function if shared,
I would really like a permission for the broker to opt in/out of services
of it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/
v2.12/spec.md#catalog-management) is too much to ask. Unless there is
some complexity I'm not seeing?


Thanks,
Mike


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

Mike Youngstrom
 

That said, this isn't a big deal. if it were a difficult thing for the
platform to allow a broker to opt out of sharing then I would say forget
about it. I'm only thinking that since the platform already has a
mechanism seemingly purpose built for this type of scenario (requires
permissions) why not be on the safe side and take the simple step of
utilizing that solution to help alleviate the issues this feature may
present to a small number of brokers?

Again, if adding a simple broker permission introduces some complexity I'm
not seeing then go ahead and drop the whole idea. I don't want this
feedback to derail the momentum in place to get shared services
implemented. This is too important of a feature to have delayed because of
feedback as minor as this.

Mike

On Sun, Aug 27, 2017 at 3:07 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:


Could you share more on the service you have developed that will not work
if bound to from another org/space?

What extra information would it need to function correctly?
Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some
cases wouldn't be pretty. For example, I have a broker that today on
provision grants an ASG to the space the service is provisioned and removes
the ASG on deprovision. If this service were to be shared I would need to
instead listen on bind get the application the service is being bound to
and add an ASG to that space. Then on unbind I'd need to see if all the
applications in the space with the binding are unbound from the service and
remove the ASG or to cleanup I'd need to continually scan the CC to see if
there are any spaces with this ASG without an instance of the service and
clean it up. Not impossible but a pain for a service that I might not be
worth the effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has had
in the past. We've considered using unbindable services as a way to add
meta data like billing or CI information to a space. This might not be a
service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC. These
brokers might utilize the space guid in some way such as ensuring the space
is authorized to create instances of this service in some billing system,
for example, because this service hasn't been trusted with admin access to
the CC it would have no way to know that another space is also using the
service. This information might be significant to the billing model of the
service.

Adding service broker lifecycle events to notify a broker of sharing and
unsharing might help these types of use cases to be handled by a broker.
But, I think that would not be something prudent to attempt to tackled for
this initial release.

Since the service broker api is one of the few open/stable extension
points on the cloud controller you might be surprised at some of the the
odd things customers have done with custom service brokers. It seems to me
that instead of requiring all services to support sharing it would be
prudent to allow services to opt out (or in) to this new feature.

Thanks,
Mike




On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?

* 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.
IMO as a broker developer of services that will not function if shared,
I would really like a permission for the broker to opt in/out of services
of it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/
v2.12/spec.md#catalog-management) is too much to ask. Unless there is
some complexity I'm not seeing?


Thanks,
Mike


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

Mike Youngstrom
 



Could you share more on the service you have developed that will not work
if bound to from another org/space?

What extra information would it need to function correctly?
Good point. I should have clarified I have services today that won't
function *without modification*. That said, the modification in some cases
wouldn't be pretty. For example, I have a broker that today on provision
grants an ASG to the space the service is provisioned and removes the ASG
on deprovision. If this service were to be shared I would need to instead
listen on bind get the application the service is being bound to and add an
ASG to that space. Then on unbind I'd need to see if all the applications
in the space with the binding are unbound from the service and remove the
ASG or to cleanup I'd need to continually scan the CC to see if there are
any spaces with this ASG without an instance of the service and clean it
up. Not impossible but a pain for a service that I might not be worth the
effort enable sharing on.

I don't have this situation yet, but, this it is an idea my group has had
in the past. We've considered using unbindable services as a way to add
meta data like billing or CI information to a space. This might not be a
service we'd want shared because the meta data might be specific to the
space it was created in. With such a service we would probably have
validation logic in place to allow only one instance of this service to be
provisioned per space. The ability to share this service would circumvent
this validation logic and perhaps break the components that operate on this
service.

There may be other services who cannot have admin access to the CC. These
brokers might utilize the space guid in some way such as ensuring the space
is authorized to create instances of this service in some billing system,
for example, because this service hasn't been trusted with admin access to
the CC it would have no way to know that another space is also using the
service. This information might be significant to the billing model of the
service.

Adding service broker lifecycle events to notify a broker of sharing and
unsharing might help these types of use cases to be handled by a broker.
But, I think that would not be something prudent to attempt to tackled for
this initial release.

Since the service broker api is one of the few open/stable extension points
on the cloud controller you might be surprised at some of the the odd
things customers have done with custom service brokers. It seems to me that
instead of requiring all services to support sharing it would be prudent to
allow services to opt out (or in) to this new feature.

Thanks,
Mike




On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?

* 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.
IMO as a broker developer of services that will not function if shared, I
would really like a permission for the broker to opt in/out of services of
it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/
v2.12/spec.md#catalog-management) is too much to ask. Unless there is
some complexity I'm not seeing?


Thanks,
Mike


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

Alex Ley
 

*IMO as a broker developer of services that will not function if shared, I
would really like a permission for the broker to opt in/out of services of
it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission
(https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#catalog-management
<https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#catalog-management>)
is
too much to ask. Unless there is some complexity I'm not seeing?*


Could you share more on the service you have developed that will not work
if bound to from another org/space?

What extra information would it need to function correctly?

On 25 August 2017 at 17:08, Mike Youngstrom <youngm(a)gmail.com> wrote:

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io>
wrote:

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.
Interesting. That behavior is different for bindings in the owning
space. Today if a space developer wishes to delete a service in its owning
space, that is bound to applications, the operation will fail until that
service is unbound. I wonder if the CAPI or CLI team would consider
changing that behavior so that the functionality is equivalent between
shared and not shared services?

If the space developer in the owning space attempts to delete a service
and the unbind fails in a shared space then I assume the delete service
request will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?

* 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.
IMO as a broker developer of services that will not function if shared, I
would really like a permission for the broker to opt in/out of services of
it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.
md#catalog-management) is too much to ask. Unless there is some
complexity I'm not seeing?


Thanks,
Mike


CF CLI v6.29.2 Released Today

Koper, Dies <diesk@...>
 

The CF CLI team cut 6.29.2 today.
Deb, yum and Homebrew repos have been updated; binaries, installers and link to release notes are available at:

https://github.com/cloudfoundry/cli#downloads
Fixed regressions

* Refactored auth used the "login" endpoint link discovered from the authorization endpoint, instead of the authorization endpoint itself, causing it to fail in cf CLI v6.29.1 on some login server configurations. (#1210<https://github.com/cloudfoundry/cli/issues/1210>)
* Refactored ssh-code used the "login" endpoint link discovered from the authorization endpoint, instead of the "uaa" endpoint link, causing it to fail in cf CLI v6.29.1 on some login server configurations.

Updated commands

* help now displays a more concise tip to use cf help -a to see all commands. (#1200<https://github.com/cloudfoundry/cli/issues/1200>)
* ssh now displays usage in help with uppercase option values consistent with other commands, and clarifies that the pseudo-tty options are mutually exclusive.

New & updated community plugins

* service-use v1.0.1: https://github.com/cdelashmutt-pivotal/service-use
Enjoy!

Regards,
Dies Koper
Cloud Foundry Product Manager - CLI


Re: Sample .NET hello_world app

Zach Brown
 

Looks good!

On Fri, Aug 25, 2017 at 8:43 AM, Chris Clark <cclark(a)cloudfoundry.org>
wrote:

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>



--

*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
 

Thanks for the response! See comments inline:

On Fri, Aug 25, 2017 at 8:48 AM, Matt McNeeney <mmcneeney(a)pivotal.io> wrote:

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.
Interesting. That behavior is different for bindings in the owning space.
Today if a space developer wishes to delete a service in its owning space,
that is bound to applications, the operation will fail until that service
is unbound. I wonder if the CAPI or CLI team would consider changing that
behavior so that the functionality is equivalent between shared and not
shared services?

If the space developer in the owning space attempts to delete a service and
the unbind fails in a shared space then I assume the delete service request
will also fail correct?

* 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.
If the org manager of an org who has a space with a shared service in it
wishes to delete the space a service is shared in, then I assume that would
succeed without the owning space developer first unsharing the service
correct? If so it seems kind of strange they can unshare the service by
deleting the space but not by simply unsharing it individually. Why not
let the space developer of a space a service is shared into let that space
developer unshare the service? Is there some hidden complexity I'm missing?

* 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.
IMO as a broker developer of services that will not function if shared, I
would really like a permission for the broker to opt in/out of services of
it's type being shared. I'd hate for my users to start sharing services
that don't support sharing and then be confused as to why the shared
service doesn't work. Granted I know there is the global flag that can
turn it all off. But, I have some services that may technically never be
able to be shared. I don't think a simple "requires" permission (
https://github.com/openservicebrokerapi/servicebroker/blob/v2.12/spec.md#catalog-management)
is
too much to ask. Unless there is some complexity I'm not seeing?


Thanks,
Mike


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

2221 - 2240 of 9422