Kong migrations up/down?

Hi,

Interesting scenario that we’ve come across while designing our deployments with Helm/Kubernetes: Helm provides an infrastructure that allow an easy way to rollback deployments but that would require a kong migrations down in certain cases. Just wondering if there were any discussions for rolling back migrations? Yeah, I understand that there may be some thorn issues. Just wondering.

Regards,
Luiz

I don’t see any huge problems in doing some controlled rollbacks from time to time if the occasion requires it. I would try to keep them as isolated as possible and would try to use them as little as possible and as small as possible. Undoing a file name and then redoing it is probably fine. Undoing the creation of a new table and then recreating it can be problematic, if there was information in production already. Every kind of change requires some thought, so my first instinct would be not leaving this kind of task to an automated system (i.e. blindly doing down and then up).

There is also the fact that not all migrations are rollback-compatible in Kong. For example, this one has an "up"
method, but no “down”. This might pose problems in your deploy.

If you are (un)doing something small like a field rename, and only once, then I would say give it a try. If you are (un)doing bigger changes, or are (un)doing them systematically, I would suggest having your own set of commands, separated from Kong’s migrations. You would have to be very careful to leave things as they were initially so that Kong doesn’t misunderstand what’s happening.

Understood, thanks. This was just a thought, in case the need arises. Frankly, at this point I would be more inclined to handle rollbacks as an upgrade from Helm point of view, whereas such Helm upgrade would happen to point to a previous version of Kong and migration down would be executed offline.

Regards,
Luiz