Add API endpoint for getting view tables names

[Michal-Leszczynski]

Knowing which tables are views (both indexes and materialized) is useful information for Scylla Manager for:

• ensuring base table is repaired before view table
• not backing up and restoring views (as it is safer to just recreate them on restored base table)

Right now Scylla Manager check this information by querying system_schema.views table which requires CQL access (which is not always granted). Having a dedicated endpoint for getting all view tables would be really useful for reducing repair/backup dependency on CQL access.

From Scylla Manager perspective, such endpoint could just return all view table names, but making it accept keyspace path param could make it more versatile.

cc: @karol-kokoszka @denesb @asias

[kostja]

Erm, what's wrong with select * from system_schema.views?
I see ;)

[denesb]

Erm, what's wrong with select * from system_schema.views?

It requires CQL credentials, which the Manager doesn't always have.

[kostja]

I don't know Scylla policy, but vendors usually don't provide unauthorized access to user data, and view names are user generated. CQL way is the standard way. I mean, when does this stop? Next Scylla Manager needs to read data or DROP KEYSPACE, and we add an endpoint?

@tzach please approve.

[denesb]

You can already list all keyspace and table names via the API. Adding a filter for views is hardly an information breach.

Note that the API can only be accessed from localhost. If you have access to the node, you already have access to this information (you have access to the data dir).

[kostja]

It can be accessed by any user on the local host. The data on disk can be encrypted, the api is not.

[karol-kokoszka]

On the other hand, is it so problematic that we keep these credentials in Scylla Manager and query system keyspace ?
We need them still to do the restore and to include schema in CQL into the backup.

If user doesn't want to provide credentials, he cannot restore (using manager ofc).

[tzach]

I agree that the current API should be limited to Admin, not data,
But in this case, I agree with @denesb: adding a filter for views makes sense.

[denesb]

It can be accessed by any user on the local host. The data on disk can be encrypted, the api is not.

Directory names are not encrypted. But I see your point. I think eventually we should add TLS+auth to our API. Then we could expose it on public IPs.