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

Scale idled environments up if SSH connections are made #2583

Merged
merged 6 commits into from
Mar 29, 2021

Conversation

shreddedbacon
Copy link
Member

Checklist

  • Affected Issues have been mentioned in the Closing issues section
  • Documentation has been written/updated
  • PR title is ready for changelog and subsystem label(s) applied

With the introduction of idling to Kubernetes clusters, sometimes if an environment is idled, the user may experience an issue trying to run commands in the requested service if other services are idled.

This adds a step to the SSH connection request that will scale any idled services up. It does this before the requested service is loaded and aims to help reduce this issue.

@shreddedbacon shreddedbacon added this to the v1.14.3 milestone Mar 24, 2021
Comment on lines 143 to 152
# for unidling an entire environment and waiting for the number of `readyReplicas`
# to be 1 for each deployment, could add considerable delays for the ssh connection to establish.
# WAIT_TO_UNIDLE_SERVICES will default to false so that it just scales the deployments
# and won't wait for them to be ready, but if set to true, it will wait for `readyReplicas` to be 1
if [[ "$WAIT_TO_UNIDLE_SERVICES" =~ [Tt][Rr][Uu][Ee] ]]; then
while [[ ! $($OC get ${DEP} -o go-template --template='{{.status.readyReplicas}}') == "1" ]]
do
sleep 1
done
fi
Copy link
Contributor

Choose a reason for hiding this comment

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

I would suggest two changes:

  1. can we split the actual unidling and the waiting into two for loops? In this case we first trigger scaling of all deployments and then maybe wait for them to be available, which would probably reduce the time that we need to wait.
  2. if a deployment had 2 replicas, the --template='{{.status.readyReplicas}}') == "1" will fail, I think we should just check that is has 1 or more replicas.

Copy link
Member Author

Choose a reason for hiding this comment

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

On 1) waiting for all services in the environment to become available could add considerable delays to establishing the ssh connection though. Which is why I did it the way I did, where it unidles them but won't wait for them to become ready (unless the WAIT_TO_UNIDLE_SERVICES var is set to true, which defaults to false)

I'll fix the 1+ replica check now.

@Schnitzel Schnitzel added the 2-build-deploy Build & Deploy subsystem label Mar 25, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2-build-deploy Build & Deploy subsystem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants