Collect more legacy configurations #918
Conversation
|
🎊 PR Preview has been successfully built and deployed to https://localstack-docs-preview-pr-918.surge.sh 🎊 |
|
Lambda config sectionAs discussed, we want to un-deprecate it given that it is currently implemented in The previous description was: Lambda migration guideIn the migration guide Lambda v2, move `HOSTNAME_FROM_LAMBDA: into the section "still supported" (since LocalStack ?.?) from here:
|
| | `BIGDATA_MONO_CONTAINER` | 0.0.0 | `0`\|`1` (default) | Whether to spin Big Data services inside the LocalStack main container. Glue jobs breaks when using `BIGDATA_MONO_CONTAINER=0`. | | ||
| | `SKIP_INFRA_DOWNLOADS` | 0.0.0 | | Whether to skip downloading additional infrastructure components (e.g., specific Elasticsearch versions) | | ||
| | `STEPFUNCTIONS_LAMBDA_ENDPOINT` | 3.0.0 | `default` | This is only supported for the `legacy` provider. URL to use as the Lambda service endpoint in Step Functions. By default this is the LocalStack Lambda endpoint. Use default to select the original AWS Lambda endpoint. | | ||
| | `S3_DIR` | 3.0.0 | | This is only supported for the `legacy_v2` provider. Configure a global parent directory that contains all buckets as sub-directories (`S3_DIR=/path/to/root`) or an individual directory that will get mounted as special bucket names (`S3_DIR=/path/to/root/bucket1:bucket1`). Only available for Localstack Pro. |
There was a problem hiding this comment.
Inconsistent ordering. Consider ordering with the most-recent deprecation/removal first and then alphabetically. This would highlight the most relevant changes at the top.
There was a problem hiding this comment.
Yeah that's the plan, just still a kinda raw draft 👍
Not sure yet what's going to ultimately be the SSOT. Both options right now don't seem super appealing, especially since we're splitting configs between community and -ext as well.
There was a problem hiding this comment.
We have two use cases,
• discover options for a specific service (current focus overall)
• discover migration path for deprecations by release (current draft for deprecations/legacy)
I kinda liked having deprecations inline (ie at original place) with a prominent migration path in bold and then collect legacy variables at the bottom. Deprecations are easy to spot when working with service X and easy to find because it does not suddenly disappear to the bottom.
Ultimately, we might want to consider a data-driven approach giving more flexibility in terms of filtering and grouping...
There was a problem hiding this comment.
I'm fine with integrating the deprecations back into the main list(s) and only keeping legacy in its own "dump" below. The deprecations should theoretically not grow too big in size anyway since every major release should move a big bunch of them to the legacy section.
|
Great initiative. We should keep improving this page. For example, the order could be improved (e.g., Profiles and even LocalStack Pro get lost at the bottom) and ultimately, we might want to think about facilitating the synchronization with our codebase ... |
a9bcfae to
83f9697
Compare
Preview here: https://localstack-docs-preview-pr-918.surge.sh/references/configuration/#legacy
Follow up to #906 where I started to partition the deprecated configuration variables into
deprecatedandlegacy.I've started collecting old configuration values and when they have been removed/deprecated. I'll probably need some help verifying them but for now it should provide a good starting point.
cc @tinyg210 you've expressed interest in this in our meeting on Monday
Changes
HOSTNAME_FROM_LAMBDANext up
In a follow-up PR we should alphabetically order the rest of the non-legacy config variables as well.