Migration Logic Timeline

[kristinapathak]

We're adding logic to help with transitioning from using SNS to support webhooks to using argus, but what is the long term plan for that code? Will it be easy to remove later? Is there any work we can do now to encapsulate that code to its own package/files as much as possible for easy removal? Under what circumstances will we remove the migration code in the future?

[joe94]

For context: the scenario in which we'll need this special migration option is if we were to jump to a version of Tr1d1um with the breaking API feature for GET /hooks to filter webhooks by owner. We need this because while webhooks have an owner associated to them in Argus, webhooks coming from SNS do not have that information.

Potential way to avoid this special logic
Create a version of Tr1d1um that integrates with Argus first before making the API breaking change. A later version can then introduce the breaking change.
How would this work? This first version of Tr1d1um would store all webhooks with the owner associated to them for POST /hook but GET /hooks won't perform the API breaking filtering. Once this version fully replaces the current Tr1d1um cluster, we won't need to worry about webhooks missing owner information and we can move on to introduce the filtering feature on the next version without any special temporary logic.

[joe94]

Created #27 and #28 to address this