kubernetes
Prow: add a REST API
What would you like to be added:
I want the Prow service cluster to expose a web API so that I can programmatically trigger Prow jobs (or anything else I want to do in the future). We can currently programmatically trigger via Pub/Sub but doing it through an API would make it easier for clients.
Why is this needed:
Increase interoperability with other tools/services.
EDIT: I am currently working on this feature (I filed this issue for transparency).
Here is the design doc. You must be a member of [email protected] to be able to comment on it.
https://github.com/kubernetes/test-infra/issues/27824#tasklist-block-6b8168fc-921e-4168-a743-0bca85ccc61c
@listx: There are no sig labels on this issue. Please add an appropriate label by using one of the following commands:
/sig <group-name>/wg <group-name>/committee <group-name>
Please see the group list for a listing of the SIGs, working groups, and committees available.
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/test-infra repository.
I'm curious, isn't kubernetes API basically the thing? In OpenShift we have many things that programmatically trigger Prowjobs, and they all do it via kube API (by creating Prowjob resources in the cluster).
I'm curious, isn't kubernetes API basically the thing? In OpenShift we have many things that programmatically trigger Prowjobs, and they all do it via kube API (by creating
Prowjobresources in the cluster).
The use case is for clients that do not have access to the Prow service cluster to trigger Prow jobs, just like how we have Sub set up (but instead of Pub/Sub we want to use HTTP).
Are there any design details ..?
Access to create prowjob CRs directly is a potential security risk and it's not obvious why both Pub/Sub and the Kubernetes API cannot be used.
Are there any design details ..?
I'll share a doc soon.
Access to create prowjob CRs directly is a potential security risk
Right.
and it's not obvious why both Pub/Sub and the Kubernetes API cannot be used.
Agreed. Any new Prow API work will not try to deprecate existing methods/solutions.
EDIT: See https://docs.google.com/document/d/1v77jp1Nb5C2C2-PdV02SGViO9CyZ9SvNxCPOHyIUQeo/edit?usp=sharing for the design doc.
This is a nice feature to have. I wrote something that pulls info from the Prow but I'm parsing yaml instead of json. :(
https://github.com/knative/test-infra/blob/main/tools/provenance-generator/pkg/parse.go#L90
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.
This bot triages PRs according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the PR is closed
You can:
- Mark this PR as fresh with
/remove-lifecycle stale - Close this PR with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
Update: #28559 was merged. While it uses gRPC, it is easy to use something like https://github.com/GoogleCloudPlatform/esp-v2#features as a proxy to perform automatic HTTP transcoding (REST <-> gRPC conversion). I think we just need an integration test to test this out (adjust the integration test gangway pod to use ESPv2 as a proxy and call that with HTTP with a json payload and expect it to trigger jobs). This should be straightforward to implement.
This is currently blocked on figuring out how to test ESPv2 locally. Based on the upstream issue I linked it appears that the ESPv2 container must always talk to the Google Service Control API. We could try to run the mock Service Control server but I haven't explored this due to other priorities.
EDIT: If we're OK with not adding integration tests that integrate ESPv2, then we can close this.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
@listx Is there a doc for how to use the Prow APIs? I checked the links in this issue but didn't find the instruction doc.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle stale - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Mark this issue as fresh with
/remove-lifecycle rotten - Close this issue with
/close - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied - After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied - After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closed
You can:
- Reopen this issue with
/reopen - Mark this issue as fresh with
/remove-lifecycle rotten - Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
@k8s-triage-robot: Closing this issue, marking it as "Not Planned".
In response to this:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues according to the following rules:
- After 90d of inactivity,
lifecycle/staleis applied- After 30d of inactivity since
lifecycle/stalewas applied,lifecycle/rottenis applied- After 30d of inactivity since
lifecycle/rottenwas applied, the issue is closedYou can:
- Reopen this issue with
/reopen- Mark this issue as fresh with
/remove-lifecycle rotten- Offer to help out with Issue Triage
Please send feedback to sig-contributor-experience at kubernetes/community.
/close not-planned
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/test-infra repository.