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

"Please hold" landing pages for slow scale from zero scenarios #874

Open
Tracked by #911
worldspawn opened this issue Jan 4, 2024 · 16 comments
Open
Tracked by #911

"Please hold" landing pages for slow scale from zero scenarios #874

worldspawn opened this issue Jan 4, 2024 · 16 comments
Labels
help wanted Extra attention is needed

Comments

@worldspawn
Copy link
Contributor

Proposal

If the service is scaling from zero and maybe needs to wait for a new node to provision a nicer user XP might be to just land on a page that says "Teamcity is starting up... please wait". Could be enabled and configured in the http scaled object resource. MVP could be a very simple page saying "{SomeValueFromHttpResource} is start up please wait" and it polls.

Use-Case

Nodes can be slow (well a cpl of minutes) to start up. The experience scaling from zero in this case is pretty ordinary. The default wait time is only 30s and then you Bad Gateway or something like that.

I nice web page telling people to sit tight and wait for the magic would be a lot nicer.

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

No response

@JorTurFer
Copy link
Member

JorTurFer commented Jan 4, 2024

Hum...
It's an interesting feature, but I'm not sure about how we can implement this. I mean, a simple message it's nice, but I'm afraid about if this has to scale to serve complex HTML and how we can do this.
WDYT @tomkerkhove ?
Maybe we can allow custom messages for HTTP Errors somehow (at HTTPScaledObject level)

@thincal
Copy link

thincal commented Jan 19, 2024

I come up with similar requirement, just customizing the error message is enough for me.

@JorTurFer
Copy link
Member

@tomkerkhove ?

@lenglet-k
Copy link

i'm interesting too for this feature. Maybe have a light custom HTML by httpsScaleObject. For not afraid user, just only print a loading message.

@zroubalik
Copy link
Member

Yeah, this should be imho configurable. And serve the light custom HTML for users that want to. They should be able to provide their custom HTLM file.

@JorTurFer
Copy link
Member

JorTurFer commented Feb 14, 2024

make sense, but maybe I'd add another CRD for this, as it's something that can be reusable (or not). WDYT?
I guess that we could include the info in a more structured way, by content and return code

@thincal
Copy link

thincal commented Mar 6, 2024

by content and return code

+1

@JorTurFer JorTurFer mentioned this issue Apr 4, 2024
19 tasks
@JorTurFer JorTurFer added the help wanted Extra attention is needed label Apr 4, 2024
@thincal
Copy link

thincal commented Apr 12, 2024

Any progress here

@JorTurFer
Copy link
Member

No, currently there isn't anybody working on this, are you willing to tackle it?

@thincal
Copy link

thincal commented Apr 14, 2024

No, currently there isn't anybody working on this, are you willing to tackle it?

Yes, I could have a try. My quick idea is to add the customized response content and code into existing http-scaled-object, but it seems that there is suggestion about using a new CRD, could help explain the consideration behind?

@JorTurFer
Copy link
Member

JorTurFer commented Apr 14, 2024

Yeah, I suggested the new CRD because I can imagine a scenario where you have multiple services behind the proxy, and you want to provide a custom message for all of them.
The new CRD could be just something like:

spec:
  httpStatus: XXX (number)
  html: |
    <html>....</html>

and then, we can include in the HTTPScaledObject with something like:

spec:
  loadingTemplate: xxxxxxx
  minReplicaCount: 0
  ....

Currently, these templates can be cluster scoped and maybe in the future we can support both, clustered and namespaced.
This will keep the HTTPScaledObject cleaner because if you have to introduce the HTML within the HTTPScaledObject, it can introduce a lot of new lines (even more when you want to reuse them)

Does it make sense to you? Maybe I'm overthinking the case, and we could go just adding something inline and iterate in the future if it's something that users use

Copy link

stale bot commented Jun 13, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Jun 13, 2024
@zroubalik zroubalik removed the stale All issues that are marked as stale due to inactivity label Jun 14, 2024
@calvinbui
Copy link

Sablier has this feature: https://acouvreur.github.io/sablier/#/strategies

Copy link

stale bot commented Aug 25, 2024

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale All issues that are marked as stale due to inactivity label Aug 25, 2024
Copy link

stale bot commented Sep 1, 2024

This issue has been automatically closed due to inactivity.

@stale stale bot closed this as completed Sep 1, 2024
@github-project-automation github-project-automation bot moved this from To Triage to Done in Roadmap - KEDA HTTP Add-On Sep 1, 2024
@JorTurFer JorTurFer reopened this Sep 2, 2024
@stale stale bot removed the stale All issues that are marked as stale due to inactivity label Sep 2, 2024
@kahirokunn
Copy link
Contributor

It would be great if we could automatically inject JavaScript into the HTML to implement polling and have the feature automatically access the HTTP server as soon as it becomes available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
Status: Done
Development

No branches or pull requests

7 participants