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.

Sign up for GitHub

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

Jump to bottom

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

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

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

worldspawn opened this issue Jan 4, 2024 · 11 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 •
edited

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 •
edited

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
Open
18 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 •
edited

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 •
edited

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
help wanted Extra attention is needed
Projects
Roadmap - KEDA HTTP Add-On
Status: To Triage
Milestone
No milestone
Development

No branches or pull requests
5 participants
@zroubalik @worldspawn @thincal @JorTurFer @lenglet-k