Page tree
Skip to end of metadata
Go to start of metadata


Feature Request: Multiple Application Versions with Rollback capabilities.  Customers would like the ability to throttle requests between multiple versions of an application and service.   


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


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


Service Mockup.png


[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

  • No labels


  1. I've added some additional detail around requirements, driven from what our group would like to see from this feature.

    CDAP Concurrent Service Artifacts Versions
    We need a way to support deploying new artifact versions of a CDAP service that is opaque to active clients of that service. This will require a greater degree of control over the app deployment process and should be an alternative way to manage the service lifecycle.


    1. Deploy a new artifact version of a service without disrupting the currently running artifact version(s).
    2. The CDAP admin API can change the percentage of API calls routed to each running artifact version. By default a newly added artifact version receives zero percent of the API calls.
    3. The specific artifact versions(s) can be directly called by including an artifact version in the HTTP header
    4. The CDAP admin API can stop a specific artifact version of the app and reallocate its percent of traffic appropriately (divided based on the existing percentage allocation of the other running artifact version(s)).
    5. We should be able to trace metrics and errors to specific artifact versions

    Example scenario

    1. Artifact version 1 of MyApp with service MyService is running on the cluster and receiving 100% of the API calls.
    2. We deploy artifact version 2 of MyApp to the cluster. We start artifact version 2 of MyApp. MyService in version 1 continues to receive 100% of API calls and version 2 receives zero percent.
    3. Test MyService artifact version 2 using the artifact version HTTP header for our test API calls.
    4. We modify the percentage of traffic to send 90% of API calls to version 1 and 10% of calls to version 2.
    5. We monitor the metrics and logs from each version to ensure there are no issues with version 2.
    6. We incrementally move the percentage of API calls from version 1 to version 2 until we are completely migrated.
    7. Stop the flows and workers for artifact version 1.
    8. Start the flows and workers for artifact version 2.
    9. We stop MyService artifact version 1 so that only MyService artifact version 2 is running.

    Rollback Scenario
    Modify the percentage of API calls back to artifact version 1 from artifact version 2.


    Should the percentage be applied at the app or service level? Do we need the granularity to independently control traffic for individual services? It probably makes sense to control this at the app level.

  2. Some additional considerations:

    • An evergreen version name that behaves the same as the versionless URL
    • App version specific metrics (through tags?)
    • App version in logs in addition to run id 
    • More configurable default behavior if the app configuration is missing or strategies to prevent the need for default behavior.