Adding Route model and APIs



> On Sep 23, 2014, at 7:37 PM, Abhishek Gupta <notifications@github.com> wrote:
> 
> In pkg/route/registry/etcd/etcd.go:
> 
> > +	return etcderr.InterpretUpdateError(err, "route", route.ID)
> > +}
> > +
> > +// DeleteRoute deletes a Route specified by its ID.
> > +func (registry *Etcd) DeleteRoute(routeID string) error {
> > +	key := makeRouteKey(routeID)
> > +	err := registry.Delete(key, true)
> > +	return etcderr.InterpretDeleteError(err, "route", routeID)
> > +}
> > +
> > +// WatchRoutes begins watching for new, changed, or deleted route configurations.
> > +func (registry *Etcd) WatchRoutes(label, field labels.Selector, resourceVersion uint64) (watch.Interface, error) {
> > +	if !label.Empty() {
> > +		return nil, fmt.Errorf("label selectors are not supported on routes yet")
> > +	}
> > +	if value, found := field.RequiresExactMatch("ID"); found {
> Multiple routers can bind to the same route or they can split the routes creating a sharded routing layer - this can be done based on route labels. We could create a more complex model where either:
> 1. a route contains all the frontend mappings for a given service
> 
I don't see much value in enforcing that (vs it just being a convention)
> 2. there is a 1-1 mapping between a route resource and a frontend/alias for a service.
> 
Let's assume that one route = one frontend, but that you can have any number of front ends point to a service.  

Because a router is shared (like a node), the binding between a router and route is managed outside of user control.  Let's assume for now that multiple routes can be bound to the same alias (when other qualifiers are added), and that the route binding process and validation is up to the admin / router.  Certain environments (like online) might have more limitations.  Generally, only the first binding with a given endpoint (unique host, port, protocol, and path) is allowed.

Let's call Name "Host" now to match the terminology in SNI and HTTP.
> In case of #1, all the alias mappings to the service are in the same place.
> In case of #2, the model is simpler and we can have a flat structure where individual attributes can be used to specify DNS, protocol, path, port.
> 
> —
> Reply to this email directly or view it on GitHub.