Joe brought up an interesting problem as he is trying to put together the upgrade steps for the new space ids changes.
The particular issue is that the API server is failing to start, because it wants to populate the model cache, but that fails because we haven’t applied the changes to the database schema yet. There are hacks we can put in place (handle both the old and new format data in the model cache logic).
But really what we want is a way to run database schema changes before we need the API server running. I thought we had that functionality in the past.
Looking at the code, we have stuff like “Upgrade.Target” which can be set to DatabaseMaster which gives access to the database level “State” object.
However, UpgradeStepsWorker explicitly depends on APICallerName which establishes a connection.
Almost all of our actual upgrade steps that I see are Target(DatabaseMaster), and don’t actually do anything with the API connection. I thought we had this problem in the past and did have an answer for it. And the Target(DatabaseMaster) code in upgrades/upgrade.go PerformUpgrade does look like it is trying to pull of a StateContext vs an APIContext. But we connect to the API way before that. So while it looks like it might be lazy and not connect to the API until we have an upgrade step that needs it, it is instead done very early before any upgrade step is done.
Depedency Engine also states we can’t evaluate our dependencies outside of our Start function, so it isn’t that we could still depend on APICallerName and just not evaluate it until we know that we actually need it.