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

Update Autoscaler documentation #2968

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
Open

Update Autoscaler documentation #2968

wants to merge 10 commits into from

Conversation

Frzk
Copy link
Contributor

@Frzk Frzk commented Jan 17, 2025

Update the Autoscaler documentation:

  • Add descriptions for available metrics
  • Add more information about the Autoscaler logic
  • Add instructions for Dashboard, CLI and Terraform
  • Add a word about limitations
  • Add a word about costs

Please review thoroughly, as I have doubts regarding a few things like what happens when enabling/disabling the Autoscaler.

@Frzk Frzk self-assigned this Jan 17, 2025
@Frzk Frzk marked this pull request as ready for review January 20, 2025 14:25
Copy link

@john-scalingo john-scalingo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the metrics. Some of them will not be directly impacted by a scale up/down of an application we might put a warning to only use them if they're sure that this metric applies.

src/_posts/platform/app/2000-01-01-autoscaler.md Outdated Show resolved Hide resolved
Comment on lines 199 to 202
Finding the best scaling target for your application is not an easy task. You
should run benchmarks on your application to identify which metric is the
bottleneck. A good approach is to scale the application down to 1 container and
use a load testing tool (e.g. Vegeta) to stress test it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to link to our load testing procedure.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right, my mistake

Comment on lines 316 to 318
2. Run `terraform plan` and check if the result looks good
3. If so, run `terraform apply`
4. After a few seconds, your Autoscaler is setup and enabled

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we want to include this. This is very generic to terraform.

for available values.
2. Run `terraform plan` and check if the result looks good
3. If so, run `terraform apply`
4. After a few seconds, your Autoscaler is setup and enabled

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to add the API too ? https://developers.scalingo.com/autoscalers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question. For now we don't have it anywhere in the doc, even in the new PostgreSQL pages.
Wouldn't it feel a bit redundant with the API doc?

Comment on lines 323 to 326
When enabling an Autoscaler:
- Depending on the current state, the platform may decide to either scale-out
(i.e. boot up additional containers) or scale-in (destroy excess containers)
to fulfill its configuration.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that this has already been said. I might be interesting to say why we would want to enable an autoscaler since we said that this was done automatically at the creation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I always prefer to have things explicitly stated to remove any doubt.
(also I tested it and it doesn't seem to work as expected so, we might have questions about it)
I'll add a word about why it can be useful, you're right :)
@benjaminach: WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

I would have considered a different section order (Create, Disable, Enable) to begin with the basic use case and provide more context on why these actions exist.

That said, it's a significant improvement, and I don't want to delay the publication.

Comment on lines 363 to 365
2. Run `terraform plan` and check if the result looks good
3. If so, run `terraform apply`
4. After a few seconds, the Autoscaler is enabled and running again

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again not sure if it's needed.

Comment on lines 356 to 362
1. Update the Autoscaler `resource` in your Terraform file like so:
```tf
resource "scalingo_autoscaler" "web_autoscaler" {
[...]
disabled = false
}
```

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not needed, if an autoscaler has been created terraform will ensure that it is enabled everytime.
Since false is the default value of disabled this doesn't change anything.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should I rather specify to remove the disabled attribute then?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants