me dataset and having an upstream device implement url routing is identical to us implementing an "evergreen" url
Feature Request: Multiple Application Versions with Rollback capabilities. Customers would like the ability to throttle requests between multiple versions of an application and service.
Requirements
- User can deploy a new version of an Application while keeping the old one.
- User can control the lifecycle of a Program from a particular Application version.
- The same Service program from different Application versions can be running concurrently.
- User can control the routing of incoming Service requests to different Service versions by percentage.
- User can make Service requests to a version specific endpoint.
Design
- Introduce versioning for Application
- Application is created from Artifact, which already has versioning.
- Upon Application creation, increment the Application version by one.
- Introduce version specific REST endpoint for Application
- Path prefix as
<base-url>/namespaces/<namespace>/apps/<app-id>/versions/<app-version> - Most of the endpoints in http://docs.cdap.io/cdap/current/en/reference-manual/http-restful-api/lifecycle.html will have a version specific variant.
- Except the one for create Application.
- Existing non-version specific endpoints are aliases to the latest Application version.
- Path prefix as
- The same Service of different Application versions can be started and running concurrently.
- All of them will publish under the same service name in ZK.
- The Application version will be stored inside the ephemeral node created by that particular Service version.
- Introduce version specific REST endpoint for Service routing
- Request path is
<base-url>/namespaces/<namespace>/apps/<app-id>/versions/<app-version>/services/<service-id>/methods/<endpoint-path>
- Request path is
- Router is aware of the Service version during routing
- For version specific endpoints, router will only route to those who have matching version based on version information stored in the ZK node.
- For non-version specific endpoints, router can optionally take a version distribution configuration.
- The configuration is stored in a ZK node
- New REST API exposes from app-fabric to set the distributed for a given service
- Router will watch for changes in that node to get hold of updates in distribution
- Router will route requests based on the distributed configuration
- If the configuration is missing, it will just route randomly to all available Service containers
- The configuration is stored in a ZK node
Additional notes
Feature Request: Multiple Application Versions with Rollback capabilities. Customers would like the ability to throttle requests between multiple versions of an application and service.
[1] The request is to be able to deploy two versions of an application and service simultaneously:
Simultaneous different versions of an application services are required.
Rollback to previous version of an application is necessary.
[2] Proposed Solution: Versioning of the Application and Service
The switch in zookeper will register itself as two different names.
Technically this could be done at the namespace level.
Explicit versioning for applications is required. URL of services could be exposed in url path. We could use an evergreen URL “latest”. This is not preferred and would constitute a breaking change for existing applications.
Alternatively we could route based on a request header signifying a different version, or a content type. This would not be a breaking change, and the url by default would be evergreen.
Design Diagram
[3] Non versioned solution: Running two separate applications with services communicating to the sa