New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

more predictable behavior around table matching and defaults #250

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

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

This comment has been minimized.

Owner

sebdah commented Aug 26, 2015

This has been released in version 2.0.0!

@sebdah sebdah closed this Oct 5, 2015

@memory

This comment has been minimized.

memory commented Oct 5, 2015

yay!

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