Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Implement the Program API #651

Closed
EronWright opened this issue Sep 6, 2024 · 1 comment · Fixed by #673
Closed

Implement the Program API #651

EronWright opened this issue Sep 6, 2024 · 1 comment · Fixed by #673
Assignees
@rquitales
Labels
kind/task Work that's part of an ongoing epic resolution/fixed This issue was fixed
Milestone
0.110

Comments

@EronWright
Copy link
Contributor

EronWright commented Sep 6, 2024 •
edited
Loading

The Program API serves as way to write an inline YAML program to be deployed via the Stack API (see docs).

We need a way to feed the program to the workspace pod, during pod initialization. A couple of possible ways:

  1. Have the init container get the Program object directly from the API server. This has an RBAC implication.
  2. Have the program controller produce a downloadable artifact, akin to how GitRepository serves an artifact, and download the artifact as we do with Flux.

I have a preference for (2). Note that the Program CRD doesn't have a status block as of yet, nor does it have a controller.

For reference, here's how the GitRepository CR works:

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  creationTimestamp: "2024-07-25T17:06:15Z"
  finalizers:
    - finalizers.fluxcd.io
  generation: 1
  name: pulumi-examples
  namespace: default
  resourceVersion: "2005488"
  uid: 1b67a048-8ec1-4486-8fcc-79858a48fa35
spec:
  interval: 5m0s
  ref:
    branch: master
  timeout: 60s
  url: https://github.com/pulumi/examples.git
status:
  artifact:
    digest: sha256:bcbed45526b241ab3366707b5a58c900e9d60a1d5c385cdfe976b1306584b454
    lastUpdateTime: "2024-09-04T17:32:18Z"
    path: gitrepository/default/pulumi-examples/f143bd369afcb5455edb54c2b90ad7aaac719339.tar.gz
    revision: master@sha1:f143bd369afcb5455edb54c2b90ad7aaac719339
    size: 48988266
    url: http://source-controller.flux-system.svc.cluster.local./gitrepository/default/pulumi-examples/f143bd369afcb5455edb54c2b90ad7aaac719339.tar.gz
  conditions:
    - lastTransitionTime: "2024-09-05T21:12:31Z"
      message: stored artifact for revision 'master@sha1:f143bd369afcb5455edb54c2b90ad7aaac719339'
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Ready
    - lastTransitionTime: "2024-09-04T17:32:18Z"
      message: stored artifact for revision 'master@sha1:f143bd369afcb5455edb54c2b90ad7aaac719339'
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: ArtifactInStorage
  observedGeneration: 1
@EronWright EronWright converted this from a draft issue Sep 6, 2024
@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Sep 6, 2024
@cleverguy25
Copy link

Added to epic #586

@cleverguy25 cleverguy25 mentioned this issue Sep 6, 2024
Closed
5 tasks
@EronWright EronWright removed the needs-triage Needs attention from the triage team label Sep 6, 2024
@mikhailshilkov mikhailshilkov added the kind/task Work that's part of an ongoing epic label Sep 9, 2024
@mjeffryes mjeffryes added this to the 0.110 milestone Sep 12, 2024
@rquitales rquitales mentioned this issue Sep 20, 2024
Merged
7 tasks
rquitales added a commit that referenced this issue Sep 24, 2024
@rquitales
[V2] Program controller and file server for program objects (#673)
2a40b39 
### Proposed changes

This PR enables a Workspace pod to fetch a Program object in a similar
fashion to how it fetches Flux artifacts. We do this by exposing a HTTP
server that serves tarballs of a fully formed `Pulumi.yaml` file,
incorporating the requested Program spec. Unlike the approach with the
Flux source-controller, I've opted **not to** create/store these tar
files in local ephemeral storage in the controller pod. Instead, when
the artifact URL is accessed, the file server will fetch the requested
Program resource from the Kubernetes API server, and wrap it up in a
`Pulumi.yaml` file and tarred. This approach ensures that the most
recent Program spec is always served, and it also greatly simplifies
storage since we do not need to create a local duplicate of these
Program objects. Since the source of truth is always on cluster, we do
not need to continuously reconcile and generate new artifacts for new
generations of Programs. Should we choose to change this implementation
in the future, the current strategy using the status field to convey the
URL should make it easy to do so.

- [x] Add status field to the Program resource to advertise a
downloadable URL for the program
- [x] Scaffold a program-controller to reconcile the status/URL
- [x] Create a simple file server to serve the fully-formed Pulumi.yaml
from a Program URL
- [x] Update deployment manifests to expose the file server
- [x] Additional unit tests
- [x] Rebase PR to take in test changes
- [x] Integrate with stack-controller

### Related issues (optional)

Closes: #651
@rquitales rquitales added the resolution/fixed This issue was fixed label Sep 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rquitales rquitales

Labels
kind/task Work that's part of an ongoing epic resolution/fixed This issue was fixed
Projects
No open projects
Pulumi Kubernetes Operator v2
Status: Done
Milestone
0.110
Development

Successfully merging a pull request may close this issue.

[V2] Program controller and file server for program objects pulumi/pulumi-kubernetes-operator
6 participants
@mjeffryes @mikhailshilkov @EronWright @cleverguy25 @rquitales @pulumi-bot