{"id":39075332,"url":"https://github.com/cloud-gov/deploy-autoscaler","last_synced_at":"2026-01-17T18:26:15.663Z","repository":{"id":196657185,"uuid":"696483072","full_name":"cloud-gov/deploy-autoscaler","owner":"cloud-gov","description":"Deployment repository for deploying App Autoscaler to Cloud Foundry at cloud.gov","archived":false,"fork":false,"pushed_at":"2026-01-02T18:30:00.000Z","size":223,"stargazers_count":0,"open_issues_count":2,"forks_count":1,"subscribers_count":3,"default_branch":"main","last_synced_at":"2026-01-05T04:34:43.648Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"other","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/cloud-gov.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":"CODEOWNERS","security":"SECURITY.md","support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2023-09-25T20:44:34.000Z","updated_at":"2026-01-02T14:37:49.000Z","dependencies_parsed_at":null,"dependency_job_id":"eb00d578-3c76-4e50-9bc6-d96b58a647f5","html_url":"https://github.com/cloud-gov/deploy-autoscaler","commit_stats":null,"previous_names":["cloud-gov/cg-deploy-autoscaler","cloud-gov/deploy-autoscaler"],"tags_count":0,"template":false,"template_full_name":"cloud-gov/.github","purl":"pkg:github/cloud-gov/deploy-autoscaler","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloud-gov%2Fdeploy-autoscaler","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloud-gov%2Fdeploy-autoscaler/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloud-gov%2Fdeploy-autoscaler/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloud-gov%2Fdeploy-autoscaler/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/cloud-gov","download_url":"https://codeload.github.com/cloud-gov/deploy-autoscaler/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/cloud-gov%2Fdeploy-autoscaler/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28515466,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-17T17:57:59.192Z","status":"ssl_error","status_checked_at":"2026-01-17T17:57:52.527Z","response_time":85,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-01-17T18:26:15.535Z","updated_at":"2026-01-17T18:26:15.613Z","avatar_url":"https://github.com/cloud-gov.png","language":"Shell","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Deploying autoscaler\n\nThis is done in a few steps:\n\n 1. Create an RDS database\n 2. Create the uaa client\n 3. Create ops files for rds and loggregator certs\n 4. Deploy\n 5. Register broker\n 6. Enable the broker for an organization\n 7. Acceptance Tests\n 8. Manual Tests\n 9. Install plugin\n 10. Maintenace \u0026 Misc\n\n\nOverall instructions for install are at https://github.com/cloudfoundry/app-autoscaler-release/blob/main/README.md .  While the overall process is correct, many of the details, such as user names and base yaml files to use are incorrect.  These are corrected for in this set of instructions.  With that out of the way, let's deploy!\n\n## 1. Create RDS Database\n\n### Create autoscaler module\n\nSee https://github.com/cloud-gov/cg-provision/pull/1549 for changes made.\n\n\n\n## 2. Create UAA client\n\nInstructions say:\n\n```\nuaac client add \"autoscaler_client_id\" \\\n    --authorized_grant_types \"client_credentials\" \\\n    --authorities \"cloud_controller.read,cloud_controller.admin,uaa.resource\" \\\n    --secret \u003cAUTOSCALE_CLIENT_SECRET\u003e\n```\n\nWe'll need to add this permanently to the cf deploy, so let's modify the manifest instead of using `uaac`, the yaml to add is:\n\n\n```\ninstance_groups:\n- name: uaa\n  jobs:\n  - name: uaa\n    release: uaa\n    properties:\n      uaa:\n        clients:\n          autoscaler_client_id:\n            authorized-grant-types: client_credentials\n            authorities: cloud_controller.read,cloud_controller.admin,uaa.resource\n            secret: \"((autoscale_client_secret))\"\n\nvariables:\n- name: autoscale_client_secret\n  type: password\n\n```\n\nConverting this to an ops file is:\n\n```\n- type: replace\n  path: /instance_groups/name=uaa/jobs/name=uaa/properties/uaa/clients/autoscaler_client_id?\n  value:\n    authorized-grant-types: client_credentials\n    authorities: cloud_controller.read,cloud_controller.admin,uaa.resource\n    secret: \"((autoscaler_client_secret))\"\n\n- type: replace\n  path: /variables/-\n  value:\n    name: autoscaler_client_secret\n    type: password\n```\n\nDirty deploy this:\n\n```\nbosh -d cf-development manifest \u003e cf.yml\nvim autoscaler.yml # copy ops file contents above here\nbosh -d cf-development deploy cf.yml -o autoscaler.yml\n```\n\nResults in:\n\n```\n  variables:\n+ - name: autoscaler_client_secret\n+   type: password\n  \n  instance_groups:\n  - name: uaa\n    jobs:\n    - name: uaa\n      properties:\n        uaa:\n          clients:\n+           autoscaler_client_id:\n+             authorities: \"\u003credacted\u003e\"\n+             authorized-grant-types: \"\u003credacted\u003e\"\n+             secret: \"\u003credacted\u003e\"\n```\n\nAdded this ops file to be used in  `cg-deploy-cf/ci/pipeline.yml` with https://github.com/cloud-gov/cg-deploy-cf/pull/771\n\nTo get the secret back:\n\n```\ncredhub get -n /bosh/cf-development/autoscaler_client_secret -q\ng2REDACTEDy4\n```\n\n\n## 3. Create the ops files for deploying app-autoscaler\n\nThese have been created and reside in `bosh/opsfiles`, they are mostly based on upstream versions of the ops files.  The vast majority of the customizations are from autoscaler assuming that the name of the Cloud Foundry is named `cf`, which it is not.\n\nThe only remaining task is to upload the release, for some reason there is no built in release structure which includes the release version itself.\n\n```\ngit clone https://github.com/cloudfoundry/app-autoscaler-release.git\ncd app-autoscaler-release\n\nbosh upload-release --sha1 828ddb8484c42c4c4e0eeee401bc684857aacf57 https://bosh.io/d/github.com/cloudfoundry-incubator/app-autoscaler-release?v=11.1.1\n```\n\nAn ops file named `bosh/opsfiles/releases.yml` now holds the configuration above and is used by the pipeline.\n\n## 4. Deploy\n\nNavigate to [https://ci.fr.cloud.gov/teams/main/pipelines/deploy-autoscaler](https://ci.fr.cloud.gov/teams/main/pipelines/deploy-autoscaler) to deploy via pipeline.\n\n\n##  5. Register broker\n\nNote: The broker has already been registered in development, staging and production using the instructions below, this activity should not need to be repeated.\n\nOriginal instructions, which won't work:\n\n```\ncf create-service-broker autoscaler autoscaler_service_broker_user `bosh int ./bosh-lite/deployments/vars/autoscaler-deployment-vars.yml --path /autoscaler_service_broker_password` https://autoscalerservicebroker.bosh-lite.com\n```\n\nA number of things are wrong with this:\n\n - We have credhub in play, didn't use a vars store, so to pull the password run:\n\n   ```\n   credhub get -n /bosh/app-autoscaler/service_broker_password -q\n   ```\n\n - The username is wrong, in the manifest it is defined as `autoscaler-broker-user`\n - The URL assumes you are using bosh-lite but has the wrong suffix, the format is `app-autoscalerservicebroker.\u003csystem_domain\u003e`, the system_domain was pulled from CF and used as a variable when this was deployed\n\nTo test the broker is responding with the user, pass and url, run a `curl`:\n\n```\ncurl \"https://autoscaler-broker-user:DcREDACTEDcY@app-autoscalerservicebroker.dev.us-gov-west-1.aws-us-gov.cloud.gov/v2/catalog\"\n```\n\nThis should emit something like:\n\n```\n{\"services\":[{\"id\":\"autoscaler-guid\",\"name\":\"app-autoscaler\",\"description\":\"Automatically increase or decrease the number of application instances based on a policy you define.\",\"bindable\":true,\"instances_retrievable\":true,\"bindings_retrievable\":true,\"tags\":[\"app-autoscaler\"],\"plan_updateable\":false,\"plans\":[{\"id\":\"autoscaler-free-plan-id\",\"name\":\"autoscaler-free-plan\",\"description\":\"This is the free service plan for the Auto-Scaling service.\",\"plan_updateable\":true},{\"id\":\"acceptance-standard\",\"name\":\"acceptance-standard\",\"description\":\"This is the standard service plan for the Auto-Scaling service.\",\"plan_updateable\":false}]}]}\n```\n\nIf you get back `Unauthorized` you have the wrong user or password.\n\nNow that the broker responds with curl, log into the cf cli as an admin and run:\n\n```\ncf create-service-broker autoscaler autoscaler-broker-user DcREDACTEDcY https://app-autoscalerservicebroker.dev.us-gov-west-1.aws-us-gov.cloud.gov\n```\n\nIf successful, you should see:\n\n```\nCreating service broker autoscaler as platform.operator...\nOK\n```\n\n##  6. Enable the broker for an organization\n\nThere are two ways of enabling service access: via the pipeline and manually:\n\n\n### Enable via the pipeline (Preferred)\n\nThe pipeline uses [https://github.com/cloud-gov/cg-pipeline-tasks/blob/main/set-plan-visibility.yml](https://github.com/cloud-gov/cg-pipeline-tasks/blob/main/set-plan-visibility.yml) to set the list of orgs to enable the broker access.  There are credhub variables for each of the environments which are space delimited. To  To add additional organizations, modify the following credhub variables: \n\n```\n- name: service_organization_development\n  type: value\n  value: org1 org2\n\n- name: service_organization_staging\n  type: value\n  value: org2 org3\n\n- name: service_organization_production\n  type: value\n  value: org1 org2 org3\n```\n\n### Manual enabling (Debugging)\n\nTo enable the service broker for the `cloud-gov-operators` org:\n\n```\ncf enable-service-access app-autoscaler -o cloud-gov-operators\n\nEnabling access to all plans of service offering app-autoscaler for org cloud-gov-operators as platform.operator...\nOK\n```\n\n##  7. Acceptance Tests\n\nThe app-autoscaler-release as part of their releases includes a tarball with a precompiled test app for each release version, see this link for the [12.1.1 example](https://github.com/cloudfoundry/app-autoscaler-release/releases/download/v12.1.1/app-autoscaler-acceptance-tests-v12.1.1.tgz).  To use this tarball, you'll need to configure a `integration_config.json` with information, such as a cf user, cf api, broker credentials and other bits of information.  Once this is done, there are tests that you can run as `./bin/test test-type`.\n\nThese contain three types of tests:\n\n - broker - ~5 minutes to run \n - api - ~5 minutes to run\n - app - ~1 hour to run\n\nIn the pipeline for `cg-deploy-autoscaler`, each of these tests are configured to run after the deployment of development, staging and production as `acceptance-tests-{api,broker,app}-{development,staging,production}`.  These tests are configured to not run in parallel as each runs a `cleanup.sh` script at the end which deletes orgs with the naming convention `ASATS-*`.  Also resist the urge to add `--nodes=4 --flake-attempts=3` as ginkgo options to `bin/test`, the app tests in particular fail frequently with this enabled.\n\nThere is also a set of 3 acceptance tests for development debugging which are commented out, along with a custom resouce towards the bottom.  These exist to debug the bash and other scripting without having to wait for a deployment to development to finish first.  Please comment these back out before submitting PRs.\n\nFinally, the \"app\" tests for custom metrics require the org/space to be able to communicate to the route registrared autoscaler api endpoint.  The default CF application security group does not allow public url access so the test is customized to at runtime create an organization called `ASATS-Autoscaler-Acceptance-Tests` which has `cf bind-security-group public_networks_egress ...` applied to it.  The other tests (broker and api) use an org/space which named and created by the acceptance tests themselves.  The \"broker\" tests fail if the `ASATS-Autoscaler-Acceptance-Tests` org is used.  This is why there are two different sets of config files in `acceptance-tests.sh`.\n\n\n##  8. Manual Tests\n\n\n### CPU Example \n\nThis first test will show how to create an Autoscaler Policy based on CPU, start by creating a service instance:\n\n```\ncf create-service app-autoscaler  autoscaler-free-plan  my-autoscaler\n```\n\n\nCreate the scaling policy, unique for this service instance:\n\n```\ncat \u003c\u003c POLICY \u003e my_policy.json\n{\n  \"instance_min_count\": 1,\n  \"instance_max_count\": 4,\n  \"scaling_rules\":\n  [\n   {\n    \"metric_type\":\"cpu\",\n    \"breach_duration_secs\":60,\n    \"threshold\": 10,\n    \"operator\":\"\u003c=\",\n    \"cool_down_secs\":60,\n    \"adjustment\": \"-1\"\n   },\n   {\n    \"metric_type\": \"cpu\",\n    \"breach_duration_secs\": 60,\n    \"threshold\": 50,\n    \"operator\": \"\u003e\",\n    \"cool_down_secs\": 60,\n    \"adjustment\": \"+1\"\n   }   \n  ]\n}\nPOLICY\n```\n\n\nNow bind the service instance and policy to the sample app called `my_cf3_app`:\n\n```\ncf bind-service my_cf3_app my-autoscaler -c my_policy.json\n```\n\nThis will apply an autoscaler policy to the `my_cf3_app` which will keep the number of app instances between 1 and 4, scaling -/+ 1 app instance based on whether the CPU is under 10% or over 50%.\n\n\nTo show this working, first scale the app instances to 6 manually, you will see 6 app instances started:\n\n```\ncf scale -i 6 my_cf3_app\n\n...\nmemory usage:   256M\n     state      since                  cpu    memory          disk           details\n#0   running    2023-09-20T11:38:04Z   0.3%   52.8M of 256M   130.6M of 1G   \n#1   starting   2023-09-20T17:40:47Z   0.0%   0 of 0          0 of 0         \n#2   starting   2023-09-20T17:40:47Z   0.0%   0 of 0          0 of 0         \n#3   starting   2023-09-20T17:40:47Z   0.0%   0 of 0          0 of 0         \n#4   starting   2023-09-20T17:40:47Z   0.0%   0 of 0          0 of 0         \n#5   starting   2023-09-20T17:40:47Z   0.0%   0 of 0          0 of 0         \n```\n\nAfter a minute or so you'll see the number of app instances drop to 4 as this is what the upper boundary was set to:\n\n```\nplatform.operator@FCOH2J-FWR2F7YT cf-deployment % cf app my_cf3_app\n...\ninstances:      4/4\nmemory usage:   256M\n     state     since                  cpu     memory          disk           details\n#0   running   2023-09-20T11:38:04Z   0.2%    52.8M of 256M   130.6M of 1G   \n#1   running   2023-09-20T17:40:58Z   11.6%   49.4M of 256M   130.6M of 1G   \n#2   running   2023-09-20T17:40:53Z   0.0%    53.1M of 256M   130.6M of 1G   \n#3   running   2023-09-20T17:40:58Z   13.3%   49.3M of 256M   130.6M of 1G   \n```\n\nSince there is no load on this hello-world style app, you'll then see the number of application instances from 4, to 3, to 2, to 1 over the course of 8 or so minutes.\n\n#### To test the scale up, we'll need to add load and drop the threshold\n\nStart by creating a new policy with an 11% scale up threshold:\n\n```\ncat \u003c\u003c POLICY \u003e my_policy.json\n{\n  \"instance_min_count\": 1,\n  \"instance_max_count\": 4,\n  \"scaling_rules\":\n  [\n   {\n    \"metric_type\":\"cpu\",\n    \"breach_duration_secs\":60,\n    \"threshold\": 10,\n    \"operator\":\"\u003c=\",\n    \"cool_down_secs\":60,\n    \"adjustment\": \"-1\"\n   },\n   {\n    \"metric_type\": \"cpu\",\n    \"breach_duration_secs\": 60,\n    \"threshold\": 11,\n    \"operator\": \"\u003e\",\n    \"cool_down_secs\": 60,\n    \"adjustment\": \"+1\"\n   }   \n  ]\n}\nPOLICY\n```\n\nUnbind then bind the service instance to the app to have the policy applied, then verify the policy is dropped to 11%:\n\n```\ncf unbind-service my_cf3_app my-autoscaler\ncf bind-service my_cf3_app my-autoscaler -c my_policy.json\ncf asp my_cf3_app\n```\nThe last command uses the CF App Autoscaler plugin, see the next section for installation.  This can be skipped without impacting the test.\n\n\nIn a separate window, run the following script:\n\n```\n#!/bin/bash\n\nset -x # run in debug mode\nDURATION=300 # how long should load be applied ? - in seconds\nTPS=60 # number of requests per second\nend=$((SECONDS+$DURATION))\n#start load\nwhile [ $SECONDS -lt $end ];\ndo\n        for ((i=1;i\u003c=$TPS;i++)); do\n                curl https://my_cf3_app.dev.us-gov-west-1.aws-us-gov.cloud.gov  -o /dev/null -s -w '%{time_starttransfer}\\n' \u003e\u003e response-times.log \u0026\n        done\n        sleep 1\ndone\nwait\necho \"Load test has been completed\"\n```\n\nAfter 3 minutes you should see the number of application instances scale up to 2:\n\n```\ncf app my_cf3_app\n...\ninstances:      2/2\nmemory usage:   256M\n     state     since                  cpu    memory          disk           details\n#0   running   2023-09-20T11:38:03Z   6.4%   73.1M of 256M   130.6M of 1G   \n#1   running   2023-09-20T19:36:15Z   6.7%   60.7M of 256M   130.6M of 1G  \n```\n\nYay!\n\n### Scheduled Example\n\nThe policy below has been manipulated to be artificially low to result in the application scaling to 4 app instances during a 30 minute window:\n\n```\ncat \u003c\u003c POLICY \u003e my_policy.json\n{\n  \"instance_min_count\": 1,\n  \"instance_max_count\": 4,\n  \"scaling_rules\":\n  [\n   {\n    \"metric_type\": \"memoryused\",\n    \"breach_duration_secs\": 60,\n    \"threshold\": 0,\n    \"operator\": \"\u003e\",\n    \"cool_down_secs\": 60,\n    \"adjustment\": \"+1\"\n   }   \n  ],\n  \"schedules\": {\n    \"timezone\": \"America/New_York\",\n    \"specific_date\": [\n      {\n        \"start_date_time\": \"2024-04-23T16:30\",\n        \"end_date_time\": \"2024-04-23T17:00\",\n        \"instance_min_count\": 1,\n        \"instance_max_count\": 4,\n        \"initial_min_instance_count\": 2\n      }\n    ]\n  }\n}\nPOLICY\n```\n\nA list of timezones used are defined at [https://docs.oracle.com/middleware/12211/wcs/tag-ref/MISC/TimeZones.html](https://docs.oracle.com/middleware/12211/wcs/tag-ref/MISC/TimeZones.html)\n\nUnbind then bind the service instance to the app to have the policy applied, then verify the policy is in effect:\n\n```\ncf unbind-service my_cf3_app my-autoscaler\ncf bind-service my_cf3_app my-autoscaler -c my_policy.json\ncf asp my_cf3_app\n```\n\nChecked back after 5pm, the following scaling events had occurred:\n\n```\ncf ash my_cf3_app\n\nRetrieving scaling event history for app my_cf3_app...\nScaling Type            Status          Instance Changes        Time                            Action                                                          Error     \ndynamic                 succeeded       3-\u003e4                    2024-04-23T16:32:13-04:00       +1 instance(s) because memoryused \u003e 0MB for 60 seconds               \ndynamic                 succeeded       2-\u003e3                    2024-04-23T16:30:13-04:00       +1 instance(s) because memoryused \u003e 0MB for 60 seconds               \ndynamic                 succeeded       1-\u003e2                    2024-04-23T16:26:13-04:00       +1 instance(s) because memoryused \u003e 0MB for 60 seconds                \n```\n\nStarting from the bottom, you can see when the policy was applied at 4:26PM it immediately bumped the instances to 2 because of the `\"initial_min_instance_count\": 2`, then starting at 4:30PM it started to add 1 app instance at a time until the max of 4 was reached.\n\nNifty!\n\n\n### Looking for more examples?\n\nAll of the possible policy configurations can be found at [https://github.com/cloudfoundry/app-autoscaler-release/blob/main/docs/policy.md](https://github.com/cloudfoundry/app-autoscaler-release/blob/main/docs/policy.md) (note that custom metrics do not currently work).\n\n## 9. Install plugin\n\nTo gain more insight and view the audit trail of the app scaling up and down there is a CF plugin which can be installed:\n\n```\ncf install-plugin -r CF-Community app-autoscaler-plugin\ncf autoscaling-api https://app-autoscaler.dev.us-gov-west-1.aws-us-gov.cloud.gov\n```\n\nOnce installed you can view the history with of the scaling event above:\n\n```\ncf autoscaling-history my_cf3_app\n\nRetrieving scaling event history for app my_cf3_app...\nScaling Type            Status          Instance Changes        Time                            Action                                                          Error     \ndynamic                 succeeded       2-\u003e1                    2023-09-20T15:38:09-04:00       -1 instance(s) because cpu \u003c= 10percentage for 60 seconds            \ndynamic                 succeeded       1-\u003e2                    2023-09-20T15:36:09-04:00       +1 instance(s) because cpu \u003e 11percentage for 60 seconds \ndynamic                 succeeded       2-\u003e1                    2023-09-20T13:48:09-04:00       -1 instance(s) because cpu \u003c= 10percentage for 60 seconds            \ndynamic                 succeeded       3-\u003e2                    2023-09-20T13:46:09-04:00       -1 instance(s) because cpu \u003c= 10percentage for 60 seconds            \ndynamic                 succeeded       4-\u003e3                    2023-09-20T13:44:09-04:00       -1 instance(s) because cpu \u003c= 10percentage for 60 seconds            \ndynamic                 succeeded       6-\u003e4                    2023-09-20T13:42:09-04:00       -2 instance(s) because limited by max instances 4                    \n```\n\nTo see the CPU metrics for which the scaling up and down was decided upon, run:\n\n```\ncf autoscaling-metrics my_cf3_app cpu\n\nRetrieving aggregated cpu metrics for app my_cf3_app...\nMetrics Name            Value                   Timestamp     \ncpu                     1percentage             2023-09-20T14:02:48-04:00     \ncpu                     1percentage             2023-09-20T14:02:08-04:00     \ncpu                     1percentage             2023-09-20T14:01:28-04:00     \ncpu                     1percentage             2023-09-20T14:00:48-04:00   \n...\n```\n\n## 10. Maintenace \u0026 Misc\n\nIn no particular order:\n\n - There are two CAs and a series of certs which are maintained in credhub.  Rotation of the certs is no different than the CF ones.\n - There is an ops file called `route-registrar-tls.yml` which lays out the ground work add TLS to the route registrared endpoints and a separate set of `-rr-` certs.  The current implementation only supports mTLS which the CF gorouters don't seem to yet support.  The two CAs created in the autoscaler deployment are also included in the Gorouter's list of CAs enabled by an ops file in cg-deploy-cf.\n - Scaling of the autoscaler vms themselves will need to be figured out as customers begin to use this more, right now the sizing is optimized to keep costs down.  \n - Will also need to circle back to the RDS instances, will likely want to add REINDEX jobs to some of the tables which store metrics, scaling history and other tables which have a high frequency of deletes.\n - The defaults for data retentions for metrics history, scaling history and others are kept at the defaults defined in the spec, an example of this can be seen [here](https://github.com/cloudfoundry/app-autoscaler-release/blob/main/jobs/operator/spec#L215-L217).\n - Policies with recurring or date schedules still require scaling rules with a metric type defined.  If you want to force an app to scale at a particular make sure that the scaling rules are easy to achieve (ie: cpu \u003e 0)\n - The dynamic_policy_test.go tests for disk will fail with the default 128MB of memory in Staging and Production (oddly works fine in development), this was bumped in the configuration file to 1024 MB for the `app` tests\n - All pipeline secrets are stored in credhub, the s3 file is no longer used.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcloud-gov%2Fdeploy-autoscaler","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcloud-gov%2Fdeploy-autoscaler","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcloud-gov%2Fdeploy-autoscaler/lists"}