From ebd7fa1312325658479e62ba1c029144ae5ef730 Mon Sep 17 00:00:00 2001 From: callum-tait-pbx <52924845+callum-tait-pbx@users.noreply.github.com> Date: Mon, 8 Mar 2021 19:31:39 +0000 Subject: [PATCH 1/5] docs: fix typos and add PR link --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e509bcd611..97369dc577 100644 --- a/README.md +++ b/README.md @@ -355,11 +355,11 @@ The `HorizontalRunnerAutoscaler` will pole GitHub based on the configuration syn **Helm Config :** `syncPeriod` **Benefits of this metric** -1. Allows for multiple controllers to be deployed as each controller deployed is responsible for scaling their own runner pods on a per namespace basis. +1. Allows for multiple controllers to be deployed as each controller deployed is responsible for scaling their own runner pods on a per namespace basis. [#223](https://github.com/summerwind/actions-runner-controller/pull/223) 2. Supports named repositories server side the same as the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric [#313](https://github.com/summerwind/actions-runner-controller/pull/313) 3. Supports github organisation wide scaling without maintaining an explicit list of repositories, this is especially useful for those that are working at a larger scale. [#223](https://github.com/summerwind/actions-runner-controller/pull/223) 4. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels) -5. Supports scaling runner count on both a percentage increase / descrease basis as well as on a fixed runner count basis [#223](https://github.com/summerwind/actions-runner-controller/pull/223) [#315](https://github.com/summerwind/actions-runner-controller/pull/315) +5. Supports scaling desired runner count on both a percentage increase / decrease basis as well as on a fixed increase / decrease count basis [#223](https://github.com/summerwind/actions-runner-controller/pull/223) [#315](https://github.com/summerwind/actions-runner-controller/pull/315) **Drawbacks of this metric** 1. May not scale quick enough for some users needs as we are scaling up and down based on indicative information rather than a direct count of the workflow queue depth From 853dceec0e591f65f0f3db13d4d6967575a85d6c Mon Sep 17 00:00:00 2001 From: callum-tait-pbx <52924845+callum-tait-pbx@users.noreply.github.com> Date: Wed, 10 Mar 2021 21:48:19 +0000 Subject: [PATCH 2/5] docs: changes based on feedback --- README.md | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/README.md b/README.md index 97369dc577..7740b0670f 100644 --- a/README.md +++ b/README.md @@ -302,12 +302,12 @@ The scale out performance is controlled via the manager containers startup `--sy **Benefits of this metric** 1. Supports named repositories allowing you to restrict the runner to a specified set of repositories server side. -2. Scales quickly (within the bounds of the syncPeriod) as it will spin up the number of runners based on the depth of the workflow queue -3. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels). +2. Scales the runner count based on the actual queue depth of the jobs meaning a more 1:1 scaling of runners to queued jobs. +4. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels). **Drawbacks of this metric** 1. Repositories must be named within the scaling metric, maintaining a list of repositories may not be viable in larger environments or self-serve environments. -2. May not scale quick enough for some users needs +2. May not scale quick enough for some users needs. This metric is pull based and so the queue depth is polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag scaling. 3. Relatively large amounts of API requests required to maintain this metric, you may run in API rate limiting issues depending on the size of your environment and how aggressive your sync period configuration is @@ -355,14 +355,16 @@ The `HorizontalRunnerAutoscaler` will pole GitHub based on the configuration syn **Helm Config :** `syncPeriod` **Benefits of this metric** -1. Allows for multiple controllers to be deployed as each controller deployed is responsible for scaling their own runner pods on a per namespace basis. [#223](https://github.com/summerwind/actions-runner-controller/pull/223) -2. Supports named repositories server side the same as the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric [#313](https://github.com/summerwind/actions-runner-controller/pull/313) -3. Supports github organisation wide scaling without maintaining an explicit list of repositories, this is especially useful for those that are working at a larger scale. [#223](https://github.com/summerwind/actions-runner-controller/pull/223) -4. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels) -5. Supports scaling desired runner count on both a percentage increase / decrease basis as well as on a fixed increase / decrease count basis [#223](https://github.com/summerwind/actions-runner-controller/pull/223) [#315](https://github.com/summerwind/actions-runner-controller/pull/315) +1. Supports named repositories server side the same as the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric [#313](https://github.com/summerwind/actions-runner-controller/pull/313) +2. Supports GitHub organisation wide scaling without maintaining an explicit list of repositories, this is especially useful for those that are working at a larger scale. [#223](https://github.com/summerwind/actions-runner-controller/pull/223) +3. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels) +4. Supports scaling desired runner count on both a percentage increase / decrease basis as well as on a fixed increase / decrease count basis [#223](https://github.com/summerwind/actions-runner-controller/pull/223) [#315](https://github.com/summerwind/actions-runner-controller/pull/315) **Drawbacks of this metric** -1. May not scale quick enough for some users needs as we are scaling up and down based on indicative information rather than a direct count of the workflow queue depth +1. Scaling is based on an indicative metric rather than a direct count of the workflow queue depth unlike the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric +2. May not scale quick enough for some users needs. This metric is pull based and so the number of busy runners are polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag scaling. Additionally we are scaling up and down based on indicative information and so the desired runner count is likely to under provision new runners or overprovision them relative to the actual amount of jobs queued. + + Examples of each scaling type implemented with a `RunnerDeployment` backed by a `HorizontalRunnerAutoscaler`: From b0056f59ad30f87905e5405fc4d71f70de3b8f18 Mon Sep 17 00:00:00 2001 From: callum-tait-pbx <52924845+callum-tait-pbx@users.noreply.github.com> Date: Wed, 10 Mar 2021 21:49:09 +0000 Subject: [PATCH 3/5] docs: fixing numbers in list --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 7740b0670f..fe626608e0 100644 --- a/README.md +++ b/README.md @@ -303,7 +303,7 @@ The scale out performance is controlled via the manager containers startup `--sy **Benefits of this metric** 1. Supports named repositories allowing you to restrict the runner to a specified set of repositories server side. 2. Scales the runner count based on the actual queue depth of the jobs meaning a more 1:1 scaling of runners to queued jobs. -4. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels). +3. Like all scaling metrics, you can manage workflow allocation to the RunnerDeployment through the use of [Github labels](#runner-labels). **Drawbacks of this metric** 1. Repositories must be named within the scaling metric, maintaining a list of repositories may not be viable in larger environments or self-serve environments. From a490e372ee51356dda9b3f5780b0cb8062324eb9 Mon Sep 17 00:00:00 2001 From: callum-tait-pbx <52924845+callum-tait-pbx@users.noreply.github.com> Date: Wed, 10 Mar 2021 21:50:07 +0000 Subject: [PATCH 4/5] docs: grammer --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index fe626608e0..e3571c4077 100644 --- a/README.md +++ b/README.md @@ -307,7 +307,7 @@ The scale out performance is controlled via the manager containers startup `--sy **Drawbacks of this metric** 1. Repositories must be named within the scaling metric, maintaining a list of repositories may not be viable in larger environments or self-serve environments. -2. May not scale quick enough for some users needs. This metric is pull based and so the queue depth is polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag scaling. +2. May not scale quick enough for some users needs. This metric is pull based and so the queue depth is polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag to scaling activity. 3. Relatively large amounts of API requests required to maintain this metric, you may run in API rate limiting issues depending on the size of your environment and how aggressive your sync period configuration is @@ -362,7 +362,7 @@ The `HorizontalRunnerAutoscaler` will pole GitHub based on the configuration syn **Drawbacks of this metric** 1. Scaling is based on an indicative metric rather than a direct count of the workflow queue depth unlike the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric -2. May not scale quick enough for some users needs. This metric is pull based and so the number of busy runners are polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag scaling. Additionally we are scaling up and down based on indicative information and so the desired runner count is likely to under provision new runners or overprovision them relative to the actual amount of jobs queued. +2. May not scale quick enough for some users needs. This metric is pull based and so the number of busy runners are polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag to scaling activity. Additionally we are scaling up and down based on indicative information and so the desired runner count is likely to under provision new runners or overprovision them relative to the actual amount of jobs queued. From 99c4f0df01a746441812df7c5de0b16acdd26c5c Mon Sep 17 00:00:00 2001 From: callum-tait-pbx <52924845+callum-tait-pbx@users.noreply.github.com> Date: Thu, 11 Mar 2021 15:31:43 +0000 Subject: [PATCH 5/5] docs: better wording --- README.md | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index e3571c4077..4e38892ece 100644 --- a/README.md +++ b/README.md @@ -361,10 +361,8 @@ The `HorizontalRunnerAutoscaler` will pole GitHub based on the configuration syn 4. Supports scaling desired runner count on both a percentage increase / decrease basis as well as on a fixed increase / decrease count basis [#223](https://github.com/summerwind/actions-runner-controller/pull/223) [#315](https://github.com/summerwind/actions-runner-controller/pull/315) **Drawbacks of this metric** -1. Scaling is based on an indicative metric rather than a direct count of the workflow queue depth unlike the `TotalNumberOfQueuedAndInProgressWorkflowRuns` metric -2. May not scale quick enough for some users needs. This metric is pull based and so the number of busy runners are polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag to scaling activity. Additionally we are scaling up and down based on indicative information and so the desired runner count is likely to under provision new runners or overprovision them relative to the actual amount of jobs queued. - - +1. May not scale quick enough for some users needs. This metric is pull based and so the number of busy runners are polled as configured by the sync period, as a result scaling performance is bound by this sync period meaning there is a lag to scaling activity. +2. We are scaling up and down based on indicative information rather than a count of the actual number of queued jobs and so the desired runner count is likely to under provision new runners or overprovision them relative to actual job queue depth, this may or may not be a problem for you. Examples of each scaling type implemented with a `RunnerDeployment` backed by a `HorizontalRunnerAutoscaler`: