Soliciting feedback on a UX change for route services


Shannon Coen
 

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.


Benjamin Black
 

yes, this is how it should work.

On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


James Bayer
 

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.

regarding the UX, i have tried some explicit examples with
comments/questions below:

cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?

cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future? what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that right?
perhaps it's better to have a similar syntax to the existing route commands:

cf update-route example.com -n foo -s my-audit-service

what about supplying an external URL that is not a service on the platform?
would we do that with a user provided service instance or an explicit URL
added to the route?

# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u https://audit.example.com

how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Shannon Coen
 

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like example.com?
this cli pattern above does not really allow for that right? perhaps it's
better to have a similar syntax to the existing route commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would prefer
use of a user-provided service to keep the relationships consistent, the
parameters generic (not specific to USPIs), and limit the number of ways to
accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Mike Youngstrom
 

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like services.
Binding a service to a route is as good away as any to start users thinking
that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would prefer
use of a user-provided service to keep the relationships consistent, the
parameters generic (not specific to USPIs), and limit the number of ways to
accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io> wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a route,
requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


James Bayer
 

*I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.*

i don't think this would be a backward incompatible change to introduce a
new cli command that only needs 1 argument while keeping the syntax for 2
arguments. the commands are distinguishable based on how many arguments
there are:

cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]
cf create-route DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

so in case 1, you override the currently targeted space with the one
specified on the cli command. in case 2, you just use whatever space is
targeted.

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

--
Thank you,

James Bayer


Guillaume Berche
 

+1 for binding to a specific route (for all apps) instead of binding for
all routes of an app. One use-case that this will enable is
content-transformation service routers to only be applied on some specific
routes in order to be able measure their performance/latency impact before
extending them on other routes.

+1 for still being able to stack up multiple route services for a given
route (e.g. SSO, caching, and analytics)

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Shanon, can you please clarify that route services may still be bindeable
when this makes sense ?

For example, it might be useful for the apps bound with a router service to
be able to contact the router-service to send some control flow (e.g. for
the caching scenario to request a cache invalidation through HTCP requests
used in wikimedia https://wikitech.wikimedia.org/wiki/Multicast_HTCP_purging
<https://www.google.com/url?q=https%3A%2F%2Fwikitech.wikimedia.org%2Fwiki%2FMulticast_HTCP_purging&sa=D&sntz=1&usg=AFQjCNGsGyNfYqsIugumSD-8L2tcjm4bXQ>
). In this case, the router services would be bound to apps that need to
control it.

BTW, is there available updates on the router services model (i.e. route
service sending traffic back to the router, vs route services being exposed
to the app registry to send traffic to the app directly) ? Dieu mentionned
at the summit some pending discussions with Matt Stine around this topic
(and likely a service discovery / registry being exposed to route services
and apps), see detailed comment on the design document on section "other
proposals that were considered".

Thanks,

Guillaume.


On Wed, Jun 24, 2015 at 10:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Shannon Coen
 

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that may
not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.
This is interesting. Could you flesh this out for me? What use cases do you
have in mind for associating a service instance with a route, but not
providing a forwarding address?


I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.
Good feedback. Initially we won't support chaining services, but it does
seem worth considering a UX that doesn't prevent us from supporting this in
the future.


I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these tweaks
discussed here change the fundamental routing behavior we're proposing.
That is, that a route service url is associated with the route, and not the
app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Shannon Coen
 

Interesting idea; I'll talk to Greg O about it.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Wed, Jun 24, 2015 at 11:49 PM, James Bayer <jbayer(a)pivotal.io> wrote:

*I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.*

i don't think this would be a backward incompatible change to introduce a
new cli command that only needs 1 argument while keeping the syntax for 2
arguments. the commands are distinguishable based on how many arguments
there are:

cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]
cf create-route DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

so in case 1, you override the currently targeted space with the one
specified on the cli command. in case 2, you just use whatever space is
targeted.

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that
may not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax.
Would it be possible to bind more than one route service to a route with
that syntax? I'd prefer something like bind-route-service/unbind-route
service commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these
tweaks discussed here change the fundamental routing behavior we're
proposing. That is, that a route service url is associated with the route,
and not the app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Shannon Coen
 

On Thu, Jun 25, 2015 at 12:24 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

+1 for binding to a specific route (for all apps) instead of binding for
all routes of an app. One use-case that this will enable is
content-transformation service routers to only be applied on some specific
routes in order to be able measure their performance/latency impact before
extending them on other routes.

+1 for still being able to stack up multiple route services for a given
route (e.g. SSO, caching, and analytics)

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Shanon, can you please clarify that route services may still be bindeable
when this makes sense ?

For example, it might be useful for the apps bound with a router service
to be able to contact the router-service to send some control flow (e.g.
for the caching scenario to request a cache invalidation through HTCP
requests used in wikimedia
https://wikitech.wikimedia.org/wiki/Multicast_HTCP_purging
<https://www.google.com/url?q=https%3A%2F%2Fwikitech.wikimedia.org%2Fwiki%2FMulticast_HTCP_purging&sa=D&sntz=1&usg=AFQjCNGsGyNfYqsIugumSD-8L2tcjm4bXQ>
). In this case, the router services would be bound to apps that need to
control it.
Fair point, and thank you for the use case. Brokers have the option of
declaring whether a service is bindable or not in order to provide a better
user experience when services are not bindable (user receives a consistent
error message and no API call made to the broker). In CF we won't prevent a
service instance from being associated with a route AND an app. We'll pass
the route_service_url returned on provision to GoRouter, and any
credentials returned on bind to VCAP_SERVICES.


BTW, is there available updates on the router services model (i.e. route
service sending traffic back to the router, vs route services being exposed
to the app registry to send traffic to the app directly) ? Dieu mentionned
at the summit some pending discussions with Matt Stine around this topic
(and likely a service discovery / registry being exposed to route services
and apps), see detailed comment on the design document on section "other
proposals that were considered".
For mvp we're still planning for route services to forward requests back
through the LB and GoRouter.



Thanks,

Guillaume.


On Wed, Jun 24, 2015 at 10:51 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:

I like the idea of binding to a route instead of an app. Much simpler
conceptually when considering a route can be bound to multiple apps.

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I also have future requirements to apply functionality to a route that
may not necessarily be implemented in the form of a proxy. So, it would be
nice if this functionality were somewhat generic by not requiring a route
service to provide a proxy url and ensuring the GoRouter doesn't fail if it
comes across a route service bound to a route without a proxy url.

I'm not a fan of the proposed create-route/update-route cli syntax.
Would it be possible to bind more than one route service to a route with
that syntax? I'd prefer something like bind-route-service/unbind-route
service commands.

I cannot think of a situation where I'd like to have a route service
applied to one app but not another using the same route. The use case
doesn't really make sense given instance selection is random in that case
anyway.

As an added side bonus this approach would be simpler to implement in
NoRouter. :)

Mike

On Wed, Jun 24, 2015 at 1:30 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

Hi James,
All good suggestions; responses inline.

As we're still quite a ways from CLI work, and the proposed change is
somewhat fundamental, I'm primarily interested in determining whether
anyone has a legitimate use case for the behavior we'd like to eliminate.

On Wed, Jun 24, 2015 at 12:59 AM, James Bayer <jbayer(a)pivotal.io> wrote:

i personally don't like specifying the space in the "cf create-route"
command because it's one of the only cli commands i can think of that
requires specifying the space explicitly rather than using the currently
targeted space. i believe we should consider changing that now since a
single argument could be interpreted as the DOMAIN and the space could be
an explicit option parameter.
I agree that space isn't needed, but I don't think we can remove it from
create-route until v7; that command already exists and space is a required
argument. Seems like it would be a backwards incompatible change for now.


cf create-service audit-service free-plan my-audit-service

this seems fine, it means create a service that is expected to have a
route-service endpoint the attributes, similar to a syslog drain service
right?
Correct, in response to create-service, the service broker will return a
route_service_url.


cf update-route foo example.com -s my-audit-service

we don't have "cf update-route" today. is the reason to make the
service_instance a parameter to account for more route options in the
future?
Yes, service instance would be an optional parameter because there are
others planned for the route commands and they should be independently
configurable. E.g. path is now supported in the API and will be added to
CLI soon.

cf update-route foo example.com -s my-audit-service -p /app/path


what about a "naked domain" that does not have a hostname like
example.com? this cli pattern above does not really allow for that
right? perhaps it's better to have a similar syntax to the existing route
commands:

cf update-route example.com -n foo -s my-audit-service
Agreed, we could support route services for naked domains.


what about supplying an external URL that is not a service on the
platform? would we do that with a user provided service instance or an
explicit URL added to the route?
# using a service
cf create-route development example.com -n foo -s my-audit-service

# using an external URL
cf create-route development example.com -n foo -u
https://audit.example.com
Instead of adding a second parameter for a similar purpose, I would
prefer use of a user-provided service to keep the relationships consistent,
the parameters generic (not specific to USPIs), and limit the number of
ways to accomplish a task to a predictable, familiar minimum.


how would we remove a route-service from a route, by using a particular
option that means remove any route-service on the route?

cf update-route example.com -n foo -r
Or using the same option with an empty string:

cf update-route example.com -s ''

I'll admit, the bind/unbind metaphor works better here. Instead of using
the create-map/update-map commands, we could consider
bind-route-service/unbind-route-service.

Again, we're still a ways out from the CLI work, and none of these
tweaks discussed here change the fundamental routing behavior we're
proposing. That is, that a route service url is associated with the route,
and not the app.

Best,
Shannon

On Tue, Jun 23, 2015 at 9:14 PM, Benjamin Black <bblack(a)pivotal.io>
wrote:

yes, this is how it should work.
On Jun 23, 2015 8:11 PM, "Shannon Coen" <scoen(a)pivotal.io> wrote:

The design proposal for route services
<https://docs.google.com/document/d/1bGOQxiKkmaw6uaRWGd-sXpxL0Y28d3QihcluI15FiIA/edit?usp=sharing>
suggests the following developer workflow to trigger forwarding app
requests to a route service:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf bind-service APP SERVICE_INSTANCE

This is a familiar workflow but for these kinds of services, this
introduces a lot of complexity and potentially surprising behavior. We are
seriously considering a slightly different UX that eliminates this
complexity and we believe is more intuitive. With this change, there is a
use case which would not be supported and we'd like to hear whether anyone
would miss it.

By binding different route services to applications that share a
route, requests could be forwarded to these different services according to
GoRouter's load balancing algorithm. Imagine a route (foo.example.com)
mapped to three applications A, B, and C. App A is bound to route service
X, app B is bound to route service Y, while app C is not bound to a route
service at all. Requests to the route would be forwarded to either route
service X or to route service Y or directly to app C.

Instead of associating the route service with an application, we are
proposing associating the route service with the route. This would mean
that all requests for a route would be forwarded to the same route service,
and could not bypass it. The following CLI usage demonstrates the developer
workflow:

cf create-service SERVICE PLAN SERVICE_INSTANCE
cf update-route HOST DOMAIN [-s SERVICE_INSTANCE]
or
cf create-route SPACE DOMAIN [-n HOSTNAME] [-s SERVICE_INSTANCE]

This change would also mean that route services would not need to be
bindable, simplifying service development, as applications are not expected
to need credentials to contact the route service directly and CF doesn't
need to know the application in order to make the forwarding decision.

Let me know if you have concerns about this change in approach.

Thank you,

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


--
Thank you,

James Bayer


_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Shannon Coen
 

On Wed, Jun 24, 2015 at 1:51 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:

I'm excited to eventually bind services to more CF entities like
services. Binding a service to a route is as good away as any to start
users thinking that services could be bound to more than just an app.

I'm not a fan of the proposed create-route/update-route cli syntax. Would
it be possible to bind more than one route service to a route with that
syntax? I'd prefer something like bind-route-service/unbind-route service
commands.
Initially we're targeting support for one service per route, and
create-route/update-route accomplishes this simply. Associating multiple
services with a route isn't as simple as binding an app as they are not
independent. An order of chaining would have to be declared. In any case,
I'll admit that update-route doesn't scale well beyond a single service.
It's worth considering a UX that doesn't prevent predictable feature
enhancements.


Mike Youngstrom
 



This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be made
public facing. (Would require a broker to orchestrate stuff outside of CF
DNS, applying DoS security profiles to the route, force ssl on the front
end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be implemented
by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on a
route. Again could be implemented as a proxy if you trust X-Forwarded-For
or simply change some config on a front end load balancer no new proxy
needed.

Basically a service applied to a route could trigger and manage all kinds
of functionality not necessarily implemented as proxy orchestrated by the
GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike


Shannon Coen
 

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:


This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be implemented
by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on a
route. Again could be implemented as a proxy if you trust X-Forwarded-For
or simply change some config on a front end load balancer no new proxy
needed.

Basically a service applied to a route could trigger and manage all kinds
of functionality not necessarily implemented as proxy orchestrated by the
GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Mike Youngstrom
 

Thanks Shannon,

Though James' suggestion would work if the the service bound to a route
doesn't use a proxy then the order become irrelevant. It would be
inconvenient to have to list all of the services bound to a route every
time I wanted to add or remove a route service.

I would propose something along the lines of the way buildpack position is
managed.

#Bind Route Service
cf bind-route-service DOMAIN SERVICE [-n HOST] [-i POSITION]

#List route services and their current order
cf route-services DOMAIN [-n HOST]

Then the user can specify a position if it is important to them but use the
default if they don't care.

Mike

On Thu, Jun 25, 2015 at 4:04 PM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on a
route. Again could be implemented as a proxy if you trust X-Forwarded-For
or simply change some config on a front end load balancer no new proxy
needed.

Basically a service applied to a route could trigger and manage all kinds
of functionality not necessarily implemented as proxy orchestrated by the
GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Guillaume Berche
 

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting

Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs that
end up being associated with the app that receive the associated traffic
(e.g. cache hit or cache miss for a specific incoming request). With route
services being associated to routes (and not being bound to app instances
anymore), I'd like to re-iterate the suggestion I made in the design
document (on Feb 17) to have the gorouter include the app_id in the headers
of the signed request it sends to route service(s). This will allow for a
route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.

On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on a
route. Again could be implemented as a proxy if you trust X-Forwarded-For
or simply change some config on a front end load balancer no new proxy
needed.

Basically a service applied to a route could trigger and manage all kinds
of functionality not necessarily implemented as proxy orchestrated by the
GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Shannon Coen
 

Guillaume,

Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com> wrote:

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting

Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs that
end up being associated with the app that receive the associated traffic
(e.g. cache hit or cache miss for a specific incoming request). With route
services being associated to routes (and not being bound to app instances
anymore), I'd like to re-iterate the suggestion I made in the design
document (on Feb 17) to have the gorouter include the app_id in the headers
of the signed request it sends to route service(s). This will allow for a
route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.


On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases do
you have in mind for associating a service instance with a route, but not
providing a forwarding address?

I would imagine you could bind a service to a route any time you want to
customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on
a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.

Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.

It also occurs to me that the only time chain ordering of route services
seems to be an issue is in the case of a proxy url. So, it is unfortunate
that I'd be limited to binding only one route service when I may want to
apply all kinds of functionality to a route not implemented as a proxy
because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Guillaume Berche
 

Thanks Shannon for your feedback.

I understand there is a small window into which the pre-determined app
might not exist anymore (e.g. during blue/green deployment traffic shift).
The default behavior you're suggesting (picking a different app instance)
seems sensible to me, even though it will lead to seldom false associations.

We can imagine to refine this behavior in a second step, when use-cases of
router service being sensitive to false associations become more frequent:
allow the gorouter to comply to hints provided by the route service to tune
the behavior in case the pre-determined app might not exist anymore. The
router service could for instance augment the router-service HTTP header
with hints fields:


- missing-app-policy with one of the following values:
- reassign-app: the router transparently route the request to another
app(default)
- reject: reject the request (e.g. 502 status code with a json body
providing the currently available app ids). In this case the
route service
may reemit the request to the gorouter, specifying the second param below
- route-to-app override the predetermined app to which to route the
traffic


I'm currently planning to implement a route-service that would leverage the
app_id in the request in an "autosleep", see [1]. The "reassign-app"
default policy seems fine as a first step. The reject policy would be a
nice refinement to close this corner case.

[1]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

Guillaume.

On Sat, Jul 18, 2015 at 12:08 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Guillaume,

Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s rate-limiting

Besides, If the MVP does not include support for multiple route services,
route service implementers might be able to experiment with supporting
arbitrary params as a way for users to specify fine grain options, possibly
ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs
that end up being associated with the app that receive the associated
traffic (e.g. cache hit or cache miss for a specific incoming request).
With route services being associated to routes (and not being bound to app
instances anymore), I'd like to re-iterate the suggestion I made in the
design document (on Feb 17) to have the gorouter include the app_id in the
headers of the signed request it sends to route service(s). This will allow
for a route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.


On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases
do you have in mind for associating a service instance with a route, but
not providing a forwarding address?

I would imagine you could bind a service to a route any time you want
to customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect on
a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.

Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.

It also occurs to me that the only time chain ordering of route
services seems to be an issue is in the case of a proxy url. So, it is
unfortunate that I'd be limited to binding only one route service when I
may want to apply all kinds of functionality to a route not implemented as
a proxy because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a generic
solution to the kind of functionality applied above and that you may not
want to distract from the basic Route Services MVP to accommodate these
types of use cases. I guess I can only hope that you keep the concept of
applying non proxy functionality to a route in mind as you move through
your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Shannon Coen
 

Thank you for the interesting use case for route services, Guillaume! A
mechanism to halt idle apps does seem valuable.

I've recorded your request for including app_id and will keep an ear out
for other use cases that could leverage it, despite being out of date or
incorrect.

In the meantime, couldn't your service put to sleep all apps that share a
route, if no requests for the route are received in a given period?

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jul 30, 2015 at 3:23 AM, Guillaume Berche <bercheg(a)gmail.com> wrote:

Thanks Shannon for your feedback.

I understand there is a small window into which the pre-determined app
might not exist anymore (e.g. during blue/green deployment traffic shift).
The default behavior you're suggesting (picking a different app instance)
seems sensible to me, even though it will lead to seldom false associations.

We can imagine to refine this behavior in a second step, when use-cases of
router service being sensitive to false associations become more frequent:
allow the gorouter to comply to hints provided by the route service to tune
the behavior in case the pre-determined app might not exist anymore. The
router service could for instance augment the router-service HTTP header
with hints fields:


- missing-app-policy with one of the following values:
- reassign-app: the router transparently route the request to
another app(default)
- reject: reject the request (e.g. 502 status code with a json body
providing the currently available app ids). In this case the route service
may reemit the request to the gorouter, specifying the second param below
- route-to-app override the predetermined app to which to route the
traffic


I'm currently planning to implement a route-service that would leverage
the app_id in the request in an "autosleep", see [1]. The "reassign-app"
default policy seems fine as a first step. The reject policy would be a
nice refinement to close this corner case.

[1]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

Guillaume.

On Sat, Jul 18, 2015 at 12:08 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Guillaume,

Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s
rate-limiting

Besides, If the MVP does not include support for multiple route
services, route service implementers might be able to experiment with
supporting arbitrary params as a way for users to specify fine grain
options, possibly ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs
that end up being associated with the app that receive the associated
traffic (e.g. cache hit or cache miss for a specific incoming request).
With route services being associated to routes (and not being bound to app
instances anymore), I'd like to re-iterate the suggestion I made in the
design document (on Feb 17) to have the gorouter include the app_id in the
headers of the signed request it sends to route service(s). This will allow
for a route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.


On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases
do you have in mind for associating a service instance with a route, but
not providing a forwarding address?

I would imagine you could bind a service to a route any time you want
to customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should be
made public facing. (Would require a broker to orchestrate stuff outside
of CF DNS, applying DoS security profiles to the route, force ssl on the
front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as a
proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect
on a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.

Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.

It also occurs to me that the only time chain ordering of route
services seems to be an issue is in the case of a proxy url. So, it is
unfortunate that I'd be limited to binding only one route service when I
may want to apply all kinds of functionality to a route not implemented as
a proxy because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a
generic solution to the kind of functionality applied above and that you
may not want to distract from the basic Route Services MVP to accommodate
these types of use cases. I guess I can only hope that you keep the
concept of applying non proxy functionality to a route in mind as you move
through your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev


Guillaume Berche
 

Thanks a lot Shannon.

I agree, the proposed "app activity/inactivity" measurements fed by router
service intercepted traffic could be averaged to average "route
activity/inactivity" for all apps that were mapped to these routes in a
given period. A bit more complex data processing, but doable if app_id
is'nt provided in routed traffic.

This brings me to two other corner cases for the route service specs:

1- ensure that the gorouter will indeed route traffic to route service even
if there are zero app instances available in all apps mapped to a route, or
if all mapped apps are in the stopped state.

2- As I understand current specs, route services don't currently get
notified when they get bound or unbound to a route. They can only discover
new routes their receive when they receive incoming traffic. I wonder
whether notifying route services through a variation of the binding [1] /
unbinding endpoint was considered. Some route service would benefit from
being notified in advance that traffic for new routes will arrive soon, or
will stop happening. For example, a caching route service might purge
caches associated with a route when being notified that it was unmapped
from that route. This might also be a nice way to support route services
implemented by external load balancer that Mike Y. was proposing.

Thanks again for the great feedback you provided in the autosleep design
doc.

Guillaume.

[1] http://docs.cloudfoundry.org/services/api.html#binding

On Tue, Aug 4, 2015 at 3:38 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Thank you for the interesting use case for route services, Guillaume! A
mechanism to halt idle apps does seem valuable.

I've recorded your request for including app_id and will keep an ear out
for other use cases that could leverage it, despite being out of date or
incorrect.

In the meantime, couldn't your service put to sleep all apps that share a
route, if no requests for the route are received in a given period?

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jul 30, 2015 at 3:23 AM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

Thanks Shannon for your feedback.

I understand there is a small window into which the pre-determined app
might not exist anymore (e.g. during blue/green deployment traffic shift).
The default behavior you're suggesting (picking a different app instance)
seems sensible to me, even though it will lead to seldom false associations.

We can imagine to refine this behavior in a second step, when use-cases
of router service being sensitive to false associations become more
frequent: allow the gorouter to comply to hints provided by the route
service to tune the behavior in case the pre-determined app might not exist
anymore. The router service could for instance augment the router-service
HTTP header with hints fields:


- missing-app-policy with one of the following values:
- reassign-app: the router transparently route the request to
another app(default)
- reject: reject the request (e.g. 502 status code with a json
body providing the currently available app ids). In this case the route
service may reemit the request to the gorouter, specifying the second param
below
- route-to-app override the predetermined app to which to route
the traffic


I'm currently planning to implement a route-service that would leverage
the app_id in the request in an "autosleep", see [1]. The "reassign-app"
default policy seems fine as a first step. The reject policy would be a
nice refinement to close this corner case.

[1]
https://docs.google.com/document/d/1tMhIBX3tw7kPEOMCzKhUgmtmr26GVxyXwUTwMO71THI/edit#

Guillaume.

On Sat, Jul 18, 2015 at 12:08 AM, Shannon Coen <scoen(a)pivotal.io> wrote:

Guillaume,

Including the app_id with the request forwarded to the route service
becomes misleading/false when, upon receiving the request back from the
route service, the pre-determined app no longer has instances available. At
that time GoRouter should be able to choose a different app instance for
the route, possibly of a different app, rather than rejecting the request
or re-forwarding the request to the route service with a different app id.
Otherwise, the route service may be making false associations.

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 9:19 PM, Guillaume Berche <bercheg(a)gmail.com>
wrote:

I was about to suggest a similar UX for expressing a list of route
services, by relying on params ordering

cf update-route DOMAIN [-n HOST] (-s 'service instance' )*
cf update-route DOMAIN [-n HOST] -s caching -s https-only -s
rate-limiting

Besides, If the MVP does not include support for multiple route
services, route service implementers might be able to experiment with
supporting arbitrary params as a way for users to specify fine grain
options, possibly ordered

cf create-service large-grain-route-service -p '{ "caching": true,
"ssl_only": true, "rate_limit": 3 }'

+1 for Mike's suggestions to allow for some route services to be
implemented in an upfront LB such as no router. This might address the
latency and availability concerns in the initial MVP ("route services to
forward requests back through the LB and GoRouter")

Lastly, it seems important that route services be able to output logs
that end up being associated with the app that receive the associated
traffic (e.g. cache hit or cache miss for a specific incoming request).
With route services being associated to routes (and not being bound to app
instances anymore), I'd like to re-iterate the suggestion I made in the
design document (on Feb 17) to have the gorouter include the app_id in the
headers of the signed request it sends to route service(s). This will allow
for a route service with log_emiter scope to add entries to the proper app
through loggregator/doppler. Of course, this also means that when a route
is associated to multiple apps, the load balancing decision among app is
made prior to sending traffic to route service(s). I'd imagine the app_id
could be propagated in the signed request headers when going through route
services and finally reaching the gorouter before hitting the app (as to
preserve the stateless nature of gorouter).

Guillaume.


On Fri, Jun 26, 2015 at 12:04 AM, Shannon Coen <scoen(a)pivotal.io>
wrote:

This is great. Thank you, Mike.

FWIW, James had the following suggestion update-route could be used to
associate multiple routes, and express their chain order. We're not fixed
on this UX. We'll consider this more carefully when we get closer to the CF
CLI work.

cf update-route DOMAIN [-n HOST] [-s 'list,of,service,instances']

Shannon Coen
Product Manager, Cloud Foundry
Pivotal, Inc.

On Thu, Jun 25, 2015 at 12:58 PM, Mike Youngstrom <youngm(a)gmail.com>
wrote:


This is interesting. Could you flesh this out for me? What use cases
do you have in mind for associating a service instance with a route, but
not providing a forwarding address?

I would imagine you could bind a service to a route any time you want
to customize incoming traffic in some way. But that customization wouldn't
necessarily have to be implemented as a proxy.

Here are a few examples:

* A Public facing service as an indicator that a given route should
be made public facing. (Would require a broker to orchestrate stuff
outside of CF DNS, applying DoS security profiles to the route, force ssl
on the front end load balancer, etc.)
* A service to apply web front caching to a route. Could be done as
a proxy but could also be done by changing config in a front end load
balancer that supports caching like an F5 LTM.
* Rate limiting. Could be implemented as a proxy, or could be
implemented by applying some config in a front end load balancer
* A security service to limit client IP addresses allowed to connect
on a route. Again could be implemented as a proxy if you trust
X-Forwarded-For or simply change some config on a front end load balancer
no new proxy needed.

Basically a service applied to a route could trigger and manage all
kinds of functionality not necessarily implemented as proxy orchestrated by
the GoRouter.

It also occurs to me that the only time chain ordering of route
services seems to be an issue is in the case of a proxy url. So, it is
unfortunate that I'd be limited to binding only one route service when I
may want to apply all kinds of functionality to a route not implemented as
a proxy because user defined ordering isn't an issue.

That said I can see how it can be difficult for CF to provide a
generic solution to the kind of functionality applied above and that you
may not want to distract from the basic Route Services MVP to accommodate
these types of use cases. I guess I can only hope that you keep the
concept of applying non proxy functionality to a route in mind as you move
through your MVP.

Mike

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev

_______________________________________________
cf-dev mailing list
cf-dev(a)lists.cloudfoundry.org
https://lists.cloudfoundry.org/mailman/listinfo/cf-dev