Add Lepus - #364
Conversation
| # for the location of Lepus itself | ||
| url: https://adapter:3000 | ||
| # whether to use multiple cores | ||
| multiCore: true |
There was a problem hiding this comment.
Wouldn't it be better to decide the use of multicore based on the resource sets?
There was a problem hiding this comment.
Forking multiple worker processes across all available cores is already part of boilerplate node.JS clustering code within the app. If I only have one core then it still works running on master. I don't think it would make sense to duplicate this check in the helm chart - it would just add complexity without adding any functionality.
The multicore flag is just used to offer different potential modes of operation - in this respect I've used the same naming convention as the IoT Agents which also don't have any resource sets decision in the helm chart. It probably makes sense to do the same thing as IoTAgent-JSON, IoTAgent-Ultralight etc. to avoid different conventions. Just trying to maintain consistency - it is the same Node.js multi-threading code.
Back in the day, the IoT Agents were always single threaded and exclusively used PM2 for scaling. Eventually this was updated to allow for a multicore mode, using NodeJS clustering directly within the IoT Agent and removing the need for PM2. The default was single threading for backwards compatibility if I remember. The only use I have for multicore=false is when debugging, just to make the logs easier to read. I'm assuming that if someone wants multiple cores, they probably want to use them all by default, if they want to use PM2 they probably won't be using Kubernetes and this Helm Chart.
I can't see any harm in the helm chart defaulting to use all available cores since we're not using PM2, especially given that the multicore=trueflag with just one core still works as expected.
In order to deploy Lepus to Kubernetes clusters, a Helm-Chart should be provided.