KEDA HTTP Addon documentation

[arschles]

The KEDA HTTP Addon project is readying to release a v0.2.0 and we already have a significant amount of documentation. Currently, it's relatively disorganized in the docs/ directory (currently experimenting with the wiki in kedacore/http-add-on#296 Edit: it's much nicer to track documentation in a single repository, so didn't do this) and it would be nice to have better docs that are in a dedicated space.

Since this project is part of the KEDA organization, it seems to make sense to either be part of the keda.sh site or at least be in the same repository. I'm impartial to those logistics, I'd mostly just like to:

1. store documentation in a space dedicated to documentation
2. Be able to render those documentation in a logical way

Use-Case

Write, store and render documentation in a way that's more logical to humans.

Specification

• Move documentation here, or another place dedicated to documentation
• Render those documentation on keda.sh, GitBook, or another place dedicated to rendering documentation in a logical way that's friendly to humans

[zroubalik]

+1

Having a section on keda.sh make sense imho.

[tomkerkhove]

Agreed, I'm just thinking about where. We could have it as a "scaler" but then it has to be clear that it's not one out of the box.

[zroubalik]

A separate section, something like Addons ?

[arschles]

A separate section, something like Addons ?

Is there a plan to have other Addons? If not, what about a separate section for HTTP?

[tomkerkhove]

We have a Cosmos DB external scaler as well but I'm not sure if we should "treat them as special" external scalers.

I think HTTP is maybe a bit more exceptional scenario here, but what I have in mind is:

• We introduce "Add-ons" or "Scaler Community" which lists all external scalers from https://artifacthub.io/packages/search?kind=8&ts_query_web=keda&sort=relevance&page=1 on our website (once did POC but lost screenshot of it)
  • Stimulates the community, without us having to manage all the references
• That page has an "HTTP" subpage or link to a dedicated page for HTTP (can be dedicated in navigation, not a must)

Thoughts?

[arschles]

@tomkerkhove that approach sounds good. Having a separate section for HTTP makes sense because there is a lot of documentation already (see wiki), with scope that goes beyond just operating a scaler alongside KEDA

[arschles]

I'll submit a PR to this repository today with a prototype of what the HTTP addon documentation (not the external scaler section) might look like

[tomkerkhove]

I'm adding this to our Documentation Improvements to see how we can further improve this

[arschles]

Sounds good @tomkerkhove. I've closed kedacore/http-add-on#296 for now. Will keep all documentation in the docs/ repository in the HTTP Addon repository for now until you tell me otherwise. Also I'm happy to close #554 and wait if you have bigger ideas. Let me know

[tomkerkhove]

Sounds like a good idea, but feel free to keep #554 open!

[tomkerkhove]

This should have a seperate section on our website for external scalers that are owned by KEDA org.

[stale]

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.

[arschles]

@tomkerkhove can you add the right label to prevent the stalebot from closing this? I think it's still pending some CNCF work, but I definitely don't want to close this issue meanwhile.

[Rohithzr]

+1 for it being under keda.sh

The section Routing to the Right Service needs better explanation of the current scenario where a scalable service gets created on the "addon-namespace" and hence the ingress needs to be created on that same namespace and be pointed to keda-http-add-on-interceptor-proxy

I actually think we should not even mention "ingress-nginx" and simply say point your ingress to the service. and put the ingress-nginx part on another example somewhere.

We should also explain the scalability of the interceptor proxy and provide some stress testing results.

Happy to contribute on all points above.

[zroubalik]

@Rohithzr that would be great!

[tomkerkhove]

@nate-double-u @thisisobate Any thoughts when this one can be planned? It has been open for a while as part of the doc improvement effort