...

Plugin - An extension to an Artifact. Usually implements an interface used by Application Classes in the Artifact.

Use Case Walkthrough

1. Create an Application that uses config

...

Any existing adapters will need to be migrated. Ideally, the upgrade tool will create matching applications based on the adapter conf, but at a minimum we will simply delete existing adapters and templates.

6. Application Versioning

This was mentioned in stories 1 and 2, but versioning is now explicitly managed by CDAP.

Suppose a development team is working on a search application. There is a dev instance of CDAP running, and an initial version 0.1.0-SNAPSHOT of the artifact is deployed, and a corresponding application is created from it:

POST /namespaces/default/artifacts/searchapp --data-binary @searchapp-0.1.0-SNAPSHOT.jar
 
PUT /namespaces/default/apps/search -H 'Content-Type: application/json' -d '
{ 
  "artifact": {
    "name": "searchapp",
    "version": "0.1.0-SNAPSHOT"
  },
  "config": { 
    "stream": "docs"
  }
}'

During development, every day, a new version of the artifact is built and deployed:

POST /namespaces/default/artifacts/searchapp --data-binary @searchapp-0.1.0-SNAPSHOT.jar

This replaces the version of the artifact that was there before.  Any running programs will be using the old code, but any new programs started after the artifact is added will use the new code.  Therefore, as part of the deployment process, application programs are restarted.  After some time, the initial version of the application code is deemed ready for release.  The project version is bumped to version 0.1.0, an artifact is built and deployed to CDAP:

POST /namespaces/default/artifacts/searchapp --data-binary @searchapp-0.1.0.jar

This adds a newer version of the artifact.  This version is not a snapshot version and is therefore immutable.  Attempts to re-deploy it will fail.  Deploying the artifact has no impact on existing applications.  The 'search' application will continue to use version 0.1.0-SNAPSHOT of the artifact until it is updated to the new version:

POST /namespaces/default/apps/search/update -d '
{ 
  "artifact": {
    "name": "searchapp",
    "version": "0.1.0"
  }
}

If no config is given, the existing config will be used. Otherwise, if a config is given, it will entirely replace the existing config. Artifact version cannot be changed unless all running programs are stopped.

After some time, some bugs are found and version 0.1.1 is developed and released. The jar is built and deployed to CDAP:

POST /namespaces/default/artifacts/searchapp --data-binary @searchapp-0.1.1.jar

The application is updated to use the new version of the artifact with the bug fixes:

POST /namespaces/default/apps/search/update -d '
{ 
  "artifact": {
    "name": "searchapp",
    "version": "0.1.1"
  }
}

After some more time, additional features are added and version 0.2.0 is built and released, and the application is changed to use the new version of the artifact:

POST /namespaces/default/artifacts/searchapp --data-binary @searchapp-0.2.0.jar
 
POST /namespaces/default/apps/search/update -d '
{ 
  "artifact": {
    "name": "searchapp",
    "version": "0.2.0"
  }
}

If there is any schema evolution happening or any other backwards impacting changes, they must be handled correctly by the application logic. CDAP will not migrate data or have any guarantees of compatibility between artifact versions.

During the release, a serious bug is discovered and the application is rolled back to use the previous artifact version:

POST /namespaces/default/apps/search/update -d '
{ 
  "artifact": {
    "name": "searchapp",
    "version": "0.1.1"
  }
}

Again, no compatibility guarantees are made by CDAP.  This operation may not be safe if the application logic does not make it safe, for example if there is data written in a new format that the old code cannot understand.

RESTful API changes

Application APIs

...