New Repo: QPOptions

[davidhadas]

Use this issue type to request a new repo in knative-sandbox (or
knative, which may require additional discussion).

Repo information

Org: knative-sandbox

Repo: QPOptions

Purpose (Description):
While the QP extendibility work continues (we now have QPOptions and next will work on the ability to configure extensions, activate them etc.), a knative-sandbox/QPOptions repository will allow offering generic extendibility package(s) including:

• A package to test QPOptions (testgate)
• A package to process the QPOptions configuration (identifying which plugs to activate and give each plug its appropriate config map)
• Possibly also rtplugs (https://github.com/IBM/go-security-plugs/tree/v1.1.0/rtplugs) or a variant to enable controlled pluggability
• A list of plugs that can be used etc.

Sponsoring WG: Security

Actions to fulfill

This area is used to track the repo creation process.
The requestor and sponsoring WG lead should perform the steps listed below and cross out the checkmarks when done.
The TOC is involved only in the TOC Gate steps.

• Add this issue to the TOC project board for review. You are responsible for moving your entry on the board to "Needs Discussion" or "In Progress" as you move forward in this checklist.

You may not be able to use the Projects quick menu on this page. In that case, go to the project board and use the Add cards interface.

• Send a PR adding entries for this repo in /peribolos/knative-sandbox.yaml. Please mind the alphabetical order when adding to a list.
  • Add the repository and a description.
  • Grant Knative Admin the admin privilege.
  • Grant the sponsoring WG the write privilege.

TOC Gate: Once the TOC has approved the above, it will merge and Peribolos will create an empty repository.

• (golang) Send a PR to add aliases for knative.dev/$REPONAME import paths (sample).

• Have a lead from the sponsoring WG bootstrap the Git repository by pushing an
  appropriate "template" repository (basic,
  sample-controller,
  sample-source) to the new repository as
  a git remote. For example:

    git clone https://github.com/knative-sandbox/sample-controller.git
    cd sample-controller
    git remote add newrepo https://github.com/knative-sandbox/$REPONAME.git
    git push newrepo main

• Add your GitHub ID to the OWNERS file for your repo.

• Set up prow for a new repo

• Bootstrap your CI jobs using hack project (look at other sandbox repos for reference)

• Create a sample PR to verify Prow (e.g., edit the boilerplate README)

• Verify that within 24 hours the appropriate branch protections have been applied
  requiring tide to pass before PRs are merged.

• (optional) Send a PR adding the repo to knobots.

[evankanderson]

So far, we've tried to group repo names in sandbox based on the corresponding working group or extension point (net-, eventing-, kn-plugin-, etc)

There are a few repos that don't match this pattern, but I'd be inclined to try to introduce that pattern here.

[evankanderson]

TOC would like to have this discussed in the security WG first.

The main concern I have in the security WG is ongoing maintenance of these repositories and whether there are substantial benefits from putting these repos in the sandbox org rather than outside the Knative org. I think this is worth an in-person discussion (possibly next week, depending on whether other projects like inter-component Serving encryption have updates).

[davidhadas]

After discussion in security WG, it was decided to drop the QPOptions for now and start with a single repository for Security-Guard.