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