Make debugging and troubleshooting schema migrations easier

[marccampbell]

This is a working proposal to increase transparency and make debugging a broken migration easier.

Problem 1: When a new table is deployed using kubectl apply, it's not currently possible to use kubectl to determine if the table exists in the running schema, if it's still pending, or if it's failing to be applied due to an error.

Solution: The Status field of a Table object can contain the last successfully applied schema. Using kubectl describe <table>, we can expose both the desired schema and the running schema. This could be either a SHA of the schema or a Sequence number. The idea would be that if the cluster manager runs kubectl describe table and sees DesiredSchemaSequence: 14 and AppliedSchemaSequence: 13, they would know that there is a migration missing.

Additionally, we should show the last applied SQL and results somewhere?

Problem 2: There should be a way to dry run apply to determine what change will be applied to the database. What if there was an optional two phase deployment process where kubectl apply -f of a Table object would create a pending schema migration that contains the sql statement. Approving this (somehow?) would apply it to the schema, and updating the AppliedSchemaSequence on the table object.

[divolgin]

We should also add a STATUS column to the output of schemahero get migrations. Values should be planned, executed, approved, rejected