more predictable behavior around table matching and defaults #250

Closed
memory opened this Issue Jul 9, 2015 · 2 comments

Projects

None yet

2 participants

@memory
memory commented Jul 9, 2015

Presently, the "default" configuration only appears to apply to tables matched in each [table] section. And if a table is matched by two different regexes, the final policy applied is undefined. For example:

[default_options]
enable-reads-autoscaling = true
enable-writes-autoscaling = true

[table dontscalemebro]
enable-reads-autoscaling = false
enable-writes-autoscaling = false

[table .*]

A naive user would expect that this would result in the table dontscalemebro not being scaled, but what we would actually see is:

WARNING - Table dontscalemebro matches multiple regexps in the configuration
INFO - dontscalemebro - Consumed read units: 0%
INFO - dontscalemebro - Consumed write units: 0%
INFO - dontscalemebro - Autoscaling of reads has been disabled
INFO - dontscalemebro - Autoscaling of writes has been disabled
INFO - dontscalemebro - No need to change provisioning
INFO - dontscalemebro - Consumed read units: 0%
INFO - dontscalemebro - Consumed write units: 0%
INFO - dontscalemebro - Consumed read units: 0%
INFO - dontscalemebro - Read throttle count: 0
INFO - dontscalemebro - Consecutive read checks 1/1
INFO - dontscalemebro - Consumed write units: 0%
INFO - dontscalemebro - Write throttle count: 0
INFO - dontscalemebro - Consecutive write checks 1/1
INFO - dontscalemebro - Changing provisioning to 2 read units and 2 write units
INFO - dontscalemebro - Updating provisioning to 2 reads and 2 writes

...so in fact both the "true" and the "false" options are applied, and of course true "wins" because it actually generates an API action.

Alternatively, if you removed the [table .*] matcher from the above configuration, the dontscalemebro table will not be scaled, but neither will any other table in the account. And so there doesn't seem to be a way to really create a "default" policy with exceptions other than to pre-generate the configuration file with another program.

Can I suggest instead that we disallow multiple matches, and instead apply only the rule of the first match we find? That would allow setting [table .*] as a catchall rule and defining exception above it. I can provide a PR for this if the suggestion seems reasonable.

(It is of course possible that I've misunderstood your configuration-parsing strategy here, in which case my apologies.)

@sebdah sebdah self-assigned this Aug 5, 2015
@sebdah sebdah added this to the 2.0.x milestone Aug 5, 2015
@sebdah
Owner
sebdah commented Aug 26, 2015

This has been released in version 2.0.0!

@sebdah sebdah closed this Oct 5, 2015
@memory
memory commented Oct 5, 2015

yay!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment