Versioning Support - Applications and Services

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.
• 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>
• 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

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 same dataset and having an upstream device implement url routing is identical to us implementing an "evergreen" url