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.

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

Porch: enhancements to support building controllers #3452

Open
6 tasks
johnbelamaric opened this issue Aug 10, 2022 · 0 comments
Open
6 tasks

Porch: enhancements to support building controllers #3452

johnbelamaric opened this issue Aug 10, 2022 · 0 comments
Labels
area/porch enhancement New feature or request triaged Issue has been triaged by adding an `area/` label

Comments

@johnbelamaric
Copy link
Contributor

johnbelamaric commented Aug 10, 2022

For Nephio, the plan is to build controllers that use Porch as a southbound API. That is, we want controllers that operate on top of Porch - analogous to the UI operating on top of Porch, but an automation instead.

I build a proof-of-concept controller here: https://github.com/nephio-project/nephio-controller-poc. During that process I found a few improvements that would make the process simpler.

  • Provide a public typed Porch API client. The current one is internal, I ended up copying and adapting it as well as creating some utility functions to more easily mutate PackageRevisionResources. Or, is it sufficient to AddToScheme? I wasn't sure with an aggregated API.
  • Make it easy for controllers to leverage the fn runner (I didn't try this). Right now, the controller performs very specific mutations on the package. However, since the controller itself is driven by a resource spec, there is no reason that we can't allow that resource to identify functions to execute. This effectively expands our "orchestrator" from the kpt CLI client and basic Porch API, to a something that can be programatically accessed. Another way to think about this is to allow the external (to the package) controller operate on the package the same way a user would. A user may decide to imperatively execute a function against a package. I want my controller to be able to do that too - except it's actually declarative, just not declaratively built into the package, but rather into my controller resource. It's a slight shift in thinking so something worth discussion.
  • Support annotations, ownerRefs, finalizers on PackageRevisions. To make the controller really work, I need ownerRefs. I need to be able to identify the packages revisions I manage so I can prune properly, for example. (Support metadata fields on packagerevision resources #3550)
  • Support proper PackageRevision deletion. I am not sure this is working. I tried deleting a package revision from the UI and it disappeared from the UI but not from the repo.
  • A "function development mode" where the function runner Pods have imagePullPolicy: Always would be nice so during function dev I don't have to retag and update the package, etc.
  • Ways to manage the flow through the lifecycle (Package Conditions: determining when a package is ready for deployment #3455)

There are probably more and I will add to this issue as I recall them or they surface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/porch enhancement New feature or request triaged Issue has been triaged by adding an `area/` label
Projects
None yet
Development

No branches or pull requests

2 participants