[RAC-6719]: RackHD 201804 Toolchain Upgrade in Release
RackHD ToolChain Upgrade Strategy
Background (What, Why, Value)
RackHD is developed or running based on several tool chain, like NodeJS, RabbitMQ, MongoDB and even operating system like Ubuntu. As a part of long term production release, we need to keep whole tool chain upgraded in a regular basis.
Proposal of Strategy
- Will upgrade RackHD tool chain every 6 month (April => Oct => April …)
Tool chain upgrade policy
Name | Policy (by Cadence or by Need) |
Host OS | By Cadence; To track Ubuntu LTS version and use appropriate version in given cycle, ex: Ubuntu 16.04, 18.04 |
NodeJS & npm | By Cadence; To track NodeJS LTS version and use appropriate version in given cycle, ex: NodeJS 8.x, NodeJS 10.x |
MongoDB | By Cadence; To use most recent released MongoDB version in given cycle |
RabbitMQ | By Cadence; To use most recent released RabbitMQ version in given cycle |
RackHD Docker Base image | By Cadence; |
RanchOS based Microkernel | (1) Part1: RanchOS -- by Cadence (2) Part2: "docker" Microkernel base image -- by Need, will upgrade when supporting new hardware Notes: "docker" Microkernel base image is different from RackHD docker base image |
RackHD downstream NPM Package | By Cadence; Scope of Upgrade: (1) npm install warnings (2) critical packages: mango, loadash, mocha |
isc_dhcp_server | By Need |
iPXE images | By Need |
On-image-build toolchain (Dockerized now) | By Cadence |
- We'll introduce tool chain compatibility testing pipelines to validate RackHD will work normally with different version of tool chain in the scope.
- 201804 Tool Chain Upgrade Work Plan (EPIC: RAC-6719)
Notes: Based on above strategy, we’ll conduct first tool chain upgrade release in April (aka 201804 release). Next upgrade release will be 201810.
Goal of 201804 upgrade release
- Upgrade RackHD tool chain with matrix below in each flavor of release
- Introduce RackHD NPM package revision lock down feature in the release
- Optimize weekly RackHD Release version bump scheme
- Problem now: RackHD release version always gets bumped as +0.1.0 regardless API contract changes or not, small or big change
2.50.0 => 2.51.0 => 2.52.0 => Will soon become 2.99.0 …
- Plan -- still use semantic versioning
API change by Swagger differ => +0.1.0, otherwise, +0.0.1
- Fix issue that sprint release note will still be send out when CI/CD pipeline failed
Name | Current | 201804 Release |
Host OS | Ubuntu 14.04 | Ubuntu 16.04 |
NodeJS & npm | NodeJS: 4.8.7 NPM: 2.15.5 | NodeJS: 8.11.1 NPM: 5.6.0 |
MongoDB | MongoDB 3.4.9 | MongoDB: 3.6.3 |
RabbitMQ | RabbitMQ: 3.5.7 | RabbitMQ 3.6.10 |
RackHD Docker Base image | Debian-Jessie | Debin-Jessie |
Q&A
- Is the 201804 release a separate release from the weekly sprint releases?
Leo: I look “201804 release” like a “release code name” which will be actually delivered by several weekly sprint releases. So, no separate release for it.
- Do you have more info on the plan to “Introduce RackHD NPM package revision lock down feature in the release” Is this being done with a package like yarn?
Leo: We are planning to leverage package-lock feature introduced in NPM 5. (see attached)
- Also, can you help clarify the rollout strategy of the features? For example, will the 201804 Tool Chain Upgrade (and subsequent upgrades) features all be rolled out at the same time on one day or phased in as the features become available during the month they are targeted for (either April or October)?
Leo: Great question on rollout model – I think it as “phase in” model like your statement “phased in as the features become available during the month they are targeted for (either April or October)”.