community

community copied to clipboard

Use this issue type to request a new repo in knative-sandbox.

Repo information

Org: knative-sandbox

Repo: getting-started

Purpose (Description): I want to put together a "batteries included" opinionated reference deployment of Knative, including GitOps, Monitoring, Logging, Tracing, Networking and deploy it to a cluster, with the UIs public accessible.

It will run on GKE, but the only external dependancy will be an object store(GCS/S3/Minio/Azure) and a cluster with LoadBalancer capability. It is particularly geared for non GKE deployments.

It will allow people trying out knative to go to this repo, check it out, modify a few parameters and easily deploy our reference solution.

Sponsoring WG: Productivity WG

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.

• [X] 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.

I think there's some risk here that the Knative org as a whole ends up "backing" one set of plugin choices (e.g. Istio + Prometheus + Kafka) vs other plugin choices (i.e. Istio over Kong, Kourier or Contour).

I think this would be a useful exercise, but I'm not sure whether the knative org is the right place to host one particular set of integration opinions.

As Scott pointed out, this is an area where different vendors have opinions, and it may be hard to steer a course that makes a majority of the contributors happy.

It was suggested that it might be more workable to run this as a "community cluster" for supporting Knative operations like https://knative.party/. That would also allow us to say "this is how we run Knative" rather than making a statement of support of a particular vendor or component.

@upodroid is this still a thing you want to do in some form - eg. the community cluster with Knative?

yes, I'll sort it out in Dec