Highlight values that are different from the default in cluster settings

[lidorcarmel]

Is your feature request related to a problem? Please describe.
It's hard to see which cluster settings currently have a value which is different from the default when using the UI.

Describe the solution you'd like
When navigating to the cluster settings page (under /#/reports/settings), have a view that only shows the cluster settings that have a value different from the default, and another view for all settings as we have today. Probably the default view should be the new one.

Describe alternatives you've considered
I guess highlighting the values that are different from the default is also an option, but it's along scroll so it's easy to miss. In practice I think the main reason to look at settings is to get those values. The defaults are rarely interesting IMO.

Additional context
This is how it looks now:

Jira issue: CRDB-13198

Epic CRDB-13054

[Santamaura]

Hi @lidorcarmel I have started looking into this improvement and in order to move forward we need to update the endpoint with the overridden status of the settings. I'm not too familiar with settings but do you see a way to add the statuses from here:

cockroach/pkg/server/admin.go

Line 1764 in a1c1879

Public: v.Visibility() == settings.Public,

?

[Santamaura]

Would using

cockroach/pkg/settings/cluster/cluster_settings.go

Line 59 in a1c1879

OverridesInformer OverridesInformer

work?

[tbg]

internal slack thread

[Santamaura]

@thtruo @Annebirzin For the FE design side of things Lidor mentioned having a separate view so would it make sense in this case to have like a same-style table above the current one which just lists the altered settings? I'm open to thoughts/suggestions

[lidorcarmel]

another option can be to have 2 separate tabs maybe? one for the settings that have a value different from the default and one tab for everything.

[lidorcarmel]

changed the language of this issue to not use "overridden", it's a bit awkward but hopefully less confusing.
and thanks Alex for looking into this!!

[Annebirzin]

@Santamaura @lidorcarmel I was just looking into designs for this issue. I'm thinking maybe we could keep everything in one table, but update the table to add a column for 'Last override date'.

The default sort would be by override date (rather than alphabetical as it is today), so all settings with overrides would appear at the top (most recent override first). The 'Setting' column could also include an alphabetical sort so users can still see settings alphabetically.

These designs would also include an update to our current table styles (including adding the column sort option).

thoughts?

cc @thtruo

[thtruo]

I had a conversation with TSEs just now - they reacted positively to the proposed designs. They're okay with having the "last override date" and sorting the view to see all non-defaults at the top.

[ajwerner]

Designs which require adding new state to the database (like when something was set) are great, but are also take much longer as we'll need to wait a major version release and even then we won't have this data moving backwards.

For something we can do quickly and use quickly, we have a boolean and just a boolean.

update: turns out we already track it

[Santamaura]

For something we can do quickly and use quickly, we have a boolean and just a boolean.

If we instead do SELECT * FROM system.settings we could grab the 3rd column (which is the last updated TS ) and return that couldn't we?

[ajwerner]

😓 I'm sorry, I didn't realize we had that. I appologize.

[Santamaura]

No problem 😄

[lidorcarmel]

having the last override date sounds super useful, to see if the change time correlates with the issue we're debugging. and of course one table is better than 2.. thank you :)