|releng/local-charts : master||Remove restbase chart and add restrouter chart|
|releng/dev-images : master||new RESTBase image & improved build instructions|
|operations/deployment-charts : master||Modify Restrouter chart to allow for minikube development|
|operations/deployment-charts : master||Add restbase chart (port from local-charts)|
|Open||jeena||T224935 Move local-charts helm charts to a chart repository|
|Resolved||jeena||T228910 Move restbase chart from local-charts to deployment-charts repository|
Basically, once RESTRouter is fully functional, RESTBase itself will represent only the storage API layer, so to speak. We will have two options at that point: (i) keep using it; or (ii) use kask instead. In the first case, IMHO it's better to keep the service as close to the storage as possible, which would mean keep RB where it is, while in the latter case RB goes away completely.
Will RESTBase be developed and deployed from the same repo as RESTRouter? If that's the case, then (i) AND RB staying on the cassandra nodes will mean diverging methods of deployment, possibly divergent nodejs versions and base OS, with all the consequences of that (like having to upgrade cassandra nodes in tandem). Granted it will be possible to keep them in sync, but it will come at a cost which it might or might not make sense to pay. The 2 alternatives, i.e. (ii) and keeping RESTBase but moving it to kubernetes as well, don't suffer from the above, albeit they have their own costs (e.g. making sure kask is able functionally to perform RB's role, or some increased latency, although probably in the single digit ms range). It's a number of things that will have to be weighed I guess.