[Feature request] Support 'deprecated' and/or 'ignore' mapping attributes

[tburghart]

The Problem:

Over years of development, many cuttlefish schemas have accumulated baggage as configuration values become meaningless.
These schemas include numerous configuration keys that serve no purpose other than to allow deployed .conf files to be consumed without generating errors. With no easy way to flag these keys for removal, they simply accumulate, to the point that some schema files have more mapping elements accommodating oudated keys than for relevant ones.

This is most pronounced as projects transition from lager to logger and as VM options are removed (-smp, +K, etc).

Proposal(s):

One or two new mapping attribute definitions could cause a warning to be logged to help system operators start to clean out some of these old, unused keys with the eventual goal of removing the schema mappings altogether.

Attribute ignored:
Logs a warning that the key is no longer relevant and should be removed from the .conf file.
No value is written to the app.config/vm.args file.

Attribute {deprecated, Msg :: string()}:
Behavior as for ignored, but include Msg in a logged deprecation warning.
Example: Msg = "Will be removed in Riak 3.4"

My thoughts on this may not be fully formed, hence trowing it out here for feedback.

As an aside, cuttlefish/priv/erlang_vm.schema could benefit from an ignore attribute (-smp, +K)

[tburghart]

Update:
I'm working on an update that implements the above, and also applies the attributes to some old VM switches.
PR forthcoming soon-ish, though it'll be going through a circuitous path before it reaches this repo so "soon" is pretty loosely defined.

[tburghart]

For those interested, this functionality has finally been pushed to the OpenRiak cuttlefish repo with documentation in the wiki.

[michaelklishin]

@tburghart thank you. Do you think you can submit a PR to this repo or is the delta significant enough that it'd have to be manually integrated into this version of Cuttlefish?

[tburghart]

@michaelklishin The delta is significant because our branch is based off the Basho Rebar3 branch that was complete in 2017 but not yet merged to the develop branch that Kyorai is based from.

I've been merging your changes into it, and the next push will merge in your 3.4 as well as cleaning up the schema using the new attributes, so don't know where the best sync point will be.

The ultimate goal is to have the two in sync. Have a look at a diff and maybe we can figure out a strategy.

[lukebakken]

Basho Rebar3 branch that was complete in 2017

Hi @tburghart, just to confirm, it looks like the starting point for OpenRiak/cuttlefish is the develop-3.0-otp24 branch from basho/cuttlefish?

* 92127a4 - (HEAD -> openriak-3.2, origin/openriak-3.2, origin/HEAD) Update README regarding fork detachment. (9 months ago) <Ted Burghart>
* 6ab35f3 - Update CI Status badge (#2) (1 year ago) <Martin Sumner>
* ec18289 - Repoint dep (1 year ago) <Martin Sumner>
* d8b9d21 - Initial openriak branch (1 year ago) <Martin Sumner>
* b90fb9a - (origin/nhse-develop) Update rebar.config (1 year, 1 month ago) <Martin Sumner>
* 44351a7 - Update to OpenRiak (1 year, 1 month ago) <Martin Sumner>
* 4095260 - Update rebar.config (2 years, 2 months ago) <Martin Sumner>
* 3de22c1 - Redirect for nhs-develop (2 years, 2 months ago) <Martin Sumner>
*   cb3df6a - (origin/develop) Merge pull request #251 from basho/develop-3.0-otp24 (2 years, 10 months ago) <Martin Sumner>
|\
| * e4c9234 - (origin/develop-3.0-otp24) Delete rebar.lock (3 years, 4 months ago) <Martin Sumner>
| * e9a1253 - Straw clutch (3 years, 4 months ago) <Martin Sumner>
* |   6a135bb - Merge pull request #250 from basho/develop-gha-otp25 (2 years, 10 months ago) <Martin Sumner>
|\ \
| |/
|/|
| * dac706f - OTP 25 (2 years, 10 months ago) <Martin Sumner>
|/
* 9b1db4e - Correct badge reference (3 years, 4 months ago) <Martin Sumner>

[tburghart]

Yea, we snapshotted the Basho repos in 2017 with all of their branches and have developed off them internally since, with the basho/rebar3 branch being the origin of the wday-* branches.

The basho/rebar3 branch was merged into basho/develop-3.0 again in 2020.

OpenRiak was based off the NHSE repos split from bet365's Basho repos a few years ago. I think v2.0.6 (2016) might be the last direct common ancestor of all branches, but both Kyorai and NHSE commits have been merged into the wday-* branches on multiple occasions over the years.

Last year we formed OpenRiak under EEF using the NHSE repos as a base, and since then have been working on getting our internal changes pushed up onto the wday-* branches and subsequently getting it all merged into the openriak-* branches.

With 6+ years of parallel development some of the merges have been interesting, and sanitizing our internal history into what we submit to OpenRiak often gets interrupted by higher-priority tasks, which is why I'm only recently getting commits from 2023/2024 pushed ;)
With luck I'll have our Kyorai 3.4 merge pushed before long, then we'll have a clearer idea of what significant differences remain.

I think the openriak-3.2 branch was last updated from Kyorai 3.0, but as it does have the basho/rebar3 changes I think that merge won't be too hairy ...