Hide internal silos in utilization

[zephraph]

Fixes #4708.

I've updated the /v1/system/utilization/silos endpoint to only return non-discoverable silos if they have a quota set. I believe the default-silo does get a quota set currently which is non-ideal, but that should be the only one that shows up on the list.

I need specific eyes on the migration b/c I've never written a view migration before.

[david-crespo]

Strictly speaking, while this is fine to add, you don't actually need this line, right? In the query you're using it in SQL directly.

[zephraph]

Hmmm, perhaps. I thought this struct is what generated the type to use for the dsl but that might actually be from the table! call. Yeah, regardless, it shouldn't matter.

[david-crespo]

You need to be 32 so #4852 can be 31

[augustuswm]

Logically this makes sense to me. I don't know what specifically cockroachdb supports but if this is similar to postgres you may need to use CREATE OR REPLACE VIEW instead of ALTER VIEW

[zephraph]

@augustuswm pointed out using CREATE OR REPLACE VIEW so I changed it to that instead. Something I'm not sure about is what CRDB's docs say about this:

In order to replace an existing view, the new view must have the same columns as the existing view, or more. If the new view has additional columns, the old columns must be a prefix of the new columns. For example, if the existing view has columns a, b, the new view can have an additional column c, but must have columns a, b as a prefix. In this case, CREATE OR REPLACE VIEW myview (a, b, c) would be allowed, but CREATE OR REPLACE VIEW myview (b, a, c) would not.

I'm not using the parenthesis after that name in the same way they've expressed so I assume what I have is okay? It wasn't clear to me if they're saying the select order matters.

[zephraph]

I've updated the PR w/ a comment in the migration about what's being added and bumped the schema version an extra number to avoid clashing with #4852

[augustuswm]

Looks like based on the failure it might need a drop / create instead of a replace.

[zephraph]

Looks like based on the failure it might need a drop / create instead of a replace.

I reordered it such that the new column is at the end of the view and that causes it to pass. Seems like view migrations are order sensitive (which is what the docs I quoted above implied, I just didn't know if that meant for the select statement too).