RMI V2.0.0 Release Notes!

Hi all, RMI V2 is out! We are very excited with this release and want to thank you for continuously using RMI and giving feedbacks to us!

RMI V2 brings a few requested features like to delete/undeployed model/services, permanently delete a model/services, add tag to published services, etc. And, we also took this opportunities to improve under the hood performance by migrating from Helm v2 to Helm v3.

The best bit is, all of this improvements require minimal, if not none, code changes on your side.

How to Update

rmi update

Breaking Changes

Migration from Helm V2 to V3
When deploying using RMI V2, the service will be automatically upgraded to Helm V3. warning: this is not backward compatible with RMI v1.

Security – RBAC
RMI v1 depends on access token to allow jenkins to do deployment on your behalf. It worked well but there was some security concerns when the access token leaks (rest assure, it never happened until now).
In RMI v2, we remove this in favour of GCP service account. So, instead of bypassing permission check using access token, we authorize jenkins service account to execute deploy and publish actions.

Improvements rmi deploy => rmi deploy <ModelName>
Following up with access token removal, some changes need to be done on CI/CD and Scheduler/Composer setup:

...
arguments=[ "rmi", "deploy", "--no-model", "--servingRepo", "git@github.com:tvlk-data/hello-world.git"
...

to

...
arguments=[ "rmi", "deploy", "hello-world", "--no-model", "--servingRepo", "git@github.com:tvlk-data/hello-world.git"
....

3. grant your builder service account a Editor permission for your model. You can do so from https://rm-dashboard.tvlk-data.com/.

New Features

Introducing rmi delete serving <ModelName>
Use this command to delete your deployed service. This command will only take down your deployment without removing your service’s metadata from our server.

Introducing rmi destroy <ModelName>
Use this command to destroy all of RM related components. Please take note that this action is irreversible. This command will:

Introducing rmi tag serving, rmi publish --add-tag, rmi deploy --add-tag
Use this command to tag your release. We have noticed that our number of serving images have increased exponentially. Some of the services have more than 100 serving images built. It is getting hard to see which serving image is used in production yesterday, last week, last month, and so on. By introducing tagging, we hope that it can improve your in tracking the version.

References:
[1] https://cloud.google.com/cloud-build/docs/securing-builds/set-service-account-permissions
[2] https://cloud.google.com/composer/docs/how-to/managing/creating