Don't advertise qpoption in developer docs

[dprotaso]

I don't want to advertise qpoptions in the docs. It's really an implementation detail for security guard at this point.

[knative-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dprotaso

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [dprotaso]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[netlify]

✅ Deploy Preview for knative ready!

Name	Link
🔨 Latest commit	05d4122
🔍 Latest deploy log	https://app.netlify.com/projects/knative/deploys/68c898112b020800085d18e8
😎 Deploy Preview	https://deploy-preview-6372--knative.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[dprotaso]

/assign @evankanderson @davidhadas

[dprotaso]

/cherry-pick release-1.19

[knative-prow-robot]

@dprotaso: once the present PR merges, I will cherry-pick it on top of release-1.19 in a new PR and assign it to you.

In response to this:

/cherry-pick release-1.19

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[evankanderson]

/lgtm
/hold

I'll give David a day or two to weigh in.

[knative-prow]

New changes are detected. LGTM label has been removed.

[davidhadas]

What is the benefit for the community in not publishing this extendibility?
I can understand why if such publication was not available you would not spend the effort to publish it, but remove documentation when it is already there?

[dprotaso]

What is the benefit for the community in not publishing this extendibility?

It's only being used by security guard at the moment.

In the future I'd like to revisit how this mechanic works (eg. I like how envoy gateway patches work) but having it on the website will make that harder to do. eg. I'm expecting an influx of traffic from our graduation announcement.

[davidhadas]

This does not make much sense to me.

Either we are expecting an influx of traffic from our graduation announcement. In which case we may see renewed interest in the project, including in its various features such as security guard. If indeed graduation will result in teams adopting knative to production projects, they may find security features such as security guard extremely helpful.

Or that we expect a continued decline in interest in which case I can understand why we would start decreasing the project as a whole and archive parts which are not core - very possibly including security guard.

In both cases, I would suggest to wait till we see which of the two options occur to decide if it is justified to narrow the project scope and remove its features and documentation related to such features.

[dprotaso]

You're conflating security-guard with qpoptions.

I'm saying I want to revisit the mechanic of how qpoptions works thus I don't want people to write new extensions using it.

[davidhadas]

Of course we have full control over people writing new extensions using it, as such extensions would be evaluated by the community and suspended based on a new plan to do the extendability, rather than approved in serving.

We can add a sentence to the documentation to state that a new extendability feature is planned and no further use of this extendability is presently expected.

At the same time removing it will result in making it hard for people to follow how the extension presently used by security guard works. I am quite sure that security guard docs also link to these pages and rely on their content. We could with some effort clean all such references and ensure to copy the data to the security guard docs such that it will not appear in serving (although reffering to serving configs). I again suggest that this is not a productive move at this point in time, but if you insist on removing it, I would think it is wise to move it (with some rephrasing) rather than to remove it.

[evankanderson]

Sorry about the merge -- in #6398 , I moved all the versioned documentation under versioned, to separate it from the blog, testimonials, community pages that are not version-specific. You should be able to just move these files to the new location; I didn't need to change any contents.

[knative-prow-robot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.