tools/scylla-sstable: always read scylla.yaml

[denesb]

Currently, scylla.yaml is read conditionally, if either the user provided --scylla-yaml-file command line parameter, or if deducing the data dir location from the sstable path failed.
We want the scylla.yaml file to be always read, so that when working with encrypted file (enterprise), scylla-sstable can pick up the configuration for the encryption.
This patch makes scylla-sstable always attempt to read the scylla-yaml file, whether the user provided a location for it or not. When not, the default location is used (also considering the SCYLLA_CONF and SCYLLA_HOME environment variables.
Failing to find the scylla.yaml file is not considered an error. The rational is that the user will discover this if they attempt to do an operation that requires this anyway.
There is a debug-level log about whether it was successfully read or not.

Fixes: #16132

[scylladb-promoter]

🟢 CI State: SUCCESS

✅ - Build
✅ - Sanity Tests
✅ - Unit Tests

Build Details:

• Build URL: https://jenkins.scylladb.com/job/scylla-master/job/scylla-ci/4892/
• Duration: 2 hr 14 min
• Builder: spider5.cloudius-systems.com

[avikivity]

How does this impact running offline?

[denesb]

How does this impact running offline?

The tool always runs offline. I think you mean running outside a scylla-node? This is still fully supported and we have regression tests to make sure of this. Note that reading the scylla.yaml file is still optional, I just made the tool more eager to try to find and read it, to make using the tool with enterprise versions more seamless. With enterprise EAR, dumping sstables does require a scylla.yaml file, otherwise the encryption will not be set-up.

[avikivity]

How does this impact running offline?

The tool always runs offline. I think you mean running outside a scylla-node?

Yes

This is still fully supported and we have regression tests to make sure of this. Note that reading the scylla.yaml file is still optional, I just made the tool more eager to try to find and read it, to make using the tool with enterprise versions more seamless. With enterprise EAR, dumping sstables does require a scylla.yaml file, otherwise the encryption will not be set-up.

Ok, I'm worried we'll drift into requiring it more and more, but I understand the reasoning.

[denesb]

Ok, I'm worried we'll drift into requiring it more and more, but I understand the reasoning.

I share your worry and for me personally the biggest wart of sstabledump was that it only worked on a scylla node. So I will work hard to keep the support for running on downloaded sstables, on a laptop.
For now, the tool even supports providing the schema via a text file (schema.cql) and I see no reason why we couldn't keep supporting this for the foreseeable future. At least for non-encrypted sstables.

[avikivity]

Ok, I'm worried we'll drift into requiring it more and more, but I understand the reasoning.

I share your worry and for me personally the biggest wart of sstabledump was that it only worked on a scylla node. So I will work hard to keep the support for running on downloaded sstables, on a laptop. For now, the tool even supports providing the schema via a text file (schema.cql) and I see no reason why we couldn't keep supporting this for the foreseeable future. At least for non-encrypted sstables.

We could make sstables more self-contained by adding their schema to Scylla.db.

I want to add scylla --config inline-yaml-snippet (to replace --some-random-config-option=value`), this would allow copy/paste of just the encryption stuff.