Skip to content
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

[WIP][DO NOT MERGE] Proposal: Auto-scaling #546

Closed
wants to merge 8 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
updates based on feedback
  • Loading branch information
pweil- committed Dec 9, 2014
commit 2fa504c3c68e405e0da2d6dcd8dc4d91cb23daa0
9 changes: 4 additions & 5 deletions docs/autoscaling.md
Original file line number Diff line number Diff line change
Expand Up @@ -87,11 +87,10 @@ There are two options for implementing the auto-scaler:

Cons:

* May make configuration difficult when dealing with multiple auto-scalers that target the same `ReplicationController`
* Configuration collections of thresholds may be more cumbersome than json syntax.
* The entry point to logic that creates an auto-scaler is tied to the resource with annotations. For example, when
a replication controller is created either tooling that watches `ReplicationController`s needs to look for the annotations
and create a new auto-scaler OR the logic that creates the `ReplicationController` needs to do the work.
* Configuration in annotations is marginally more difficult than plain old json.
* Rather than watching explicitly for new auto-scaler definitions, the auto-scaler controller must watch all
`ReplicationController`s and create auto-scalers when appropriate. As new, auto-scalable resources are defined the
auto-scaler controller must also watch those resources.

1. As a new resource

Expand Down