Checklist
- User Stories Documented
- User Stories Reviewed
- Design Reviewed
- APIs reviewed
- Release priorities assigned
- Test cases reviewed
- Blog post
Introduction
One of the reasons CDAP must be stopped before an upgrade is so that the upgrade tool can be run to update the coprocessors for all CDAP tables. In order to minimize downtime, we would like to be able to upgrade coprocessors in a rolling fashion.
Goals
Design a method to upgrade CDAP HBase coprocessors in a rolling fashion, with minimal downtime.
User Stories
- As a cluster administrator, I want to be able to upgrade CDAP coprocessors without stopping CDAP
- As a cluster administrator, I want to be able to upgrade HBase without stopping CDAP
Design
Cover details on assumptions made, design alternatives considered, high level design
Approach
Approach #1
Approach #2
API changes
No changes to programmatic APIs
New REST APIs
No REST API changes
CLI Impact or Changes
- None
UI Impact or Changes
- None
Security Impact
What's the impact on Authorization and how does the design take care of this aspect
Impact on Infrastructure Outages
System behavior (if applicable - document impact on downstream [ YARN, HBase etc ] component failures) and how does the design take care of these aspect
Test Scenarios
| Test ID | Test Description | Expected Results |
|---|---|---|
| 1 | Run an app that uses all coprocessor features (readless increments, etc) on CDAP 3.5.2. Perform a rolling upgrade without stopping the app. | Table contents are as expected |
| 2 | Run an app that uses all coprocess features on CDAP 4.1.0. Perform a rolling upgrade of HBase without stopping the app. | Table contents are as expected |
Releases
Release 4.1.0
Related Work
- Work #1
- Work #2
- Work #3