New Repo: kn-plugin-func

[lance]

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: kn-plugin-func

Purpose (Description): Provides a function development CLI for Golang, Quarkus, Python, Node.js and SpringBoot. The plugin enables the creation of a function project, building it as an image, deploying and other developer focused workflow tasks.

The current repository is https://github.com/boson-project/func

Here is the output from kn func --help:

Serverless functions

Create, build and deploy functions in serverless containers for multiple runtimes on Knative

Usage:
  func [command]

Examples:

# Create a node function called "node-sample" and enter the directory
kn func create myfunc && cd myfunc

# Build the container image, push it to a registry and deploy it to the connected Knative cluster
# (replace <registry/user> with something like quay.io/user with an account that have you access to)
kn func deploy --registry <registry/user>

# Curl the service with the service URL
curl $(kn service describe myfunc -o url)

Available Commands:
  build       Build a function project as a container image
  completion  Generate completion scripts for bash, fish and zsh
  create      Create a function project
  delete      Undeploy a function
  deploy      Deploy a function
  describe    Show details of a function
  emit        Emit a CloudEvent to a function endpoint
  help        Help about any command
  list        List functions
  run         Run the function locally
  version     Show the version

Flags:
  -h, --help      help for func
  -v, --verbose   print verbose logs
      --version   version for func

Use "func [command] --help" for more information about a command.

Sponsoring WG: client

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.

• [x] Send a PR adding entries for this repo in /peribolos/knative-sandbox.yaml. Please mind the alphabetical order when adding to a list.
  • [x] Add the repository and a description.
  • [x] Grant Knative Admin the admin privilege.
  • [x] 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).

• [x] 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

• [x] If the new repository is a code donation check that the donated code meets the formal requirements for code donations

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

[lance]

I believe it might be necessary to add some background information to this issue in order to provide a little more clarity around the history of this project and potential longer term plans.

The boson-project organization grew from Red Hat's efforts to provide a "Functions" offering in its OpenShift Serverless product, Red Hat's supported version of Knative. Early iterations of this project were demonstrated in 2020 as part of the exploratory Knative Functions Working Group. In that time, it has evolved to be a kn plugin focused on providing a streamlined/simple developer experience. The CLI plugin provides the following commands:

• create, which generates a function project template for Go, Quarkus, Python, Node.js, TypeScript and SpringBoot. The templates are compiled into the binary, but the functionality is "pluggable" so that the provided templates can be easily expanded
• build, which utilizes the buildpack APIs to create container images on the local host. The builder images used are based on Red Hat's UBI images, but as with the templates, the buildpack builder images are also configurable
• run, which will launch a function's container image for testing on the local host
• deploy, which creates or updates the function as a Knative Service
• delete, which deletes the function's Service on the cluster
• list, which lists all deployed functions
• describe, which describes a deployed function, along with any triggers associated with the deployed Service

While this work has been done in support of Red Hat's Serverless Functions product, our hope is for it to have a life upstream as well. As I noted in the command descriptions, the pieces of this project that are explicitly tied to Red Hat technology (e.g. the buildpacks) are configurable/pluggable, providing a vendor-agnostic path forward.

The project currently does not address on-cluster builds, for workflows such as CI/CD or for environments where developers may not have the ability to create images on their local system - for example, when no Docker/Podman daemon is present. We have been following the work in Matt Moore's mink project, and have tentative plans to use or provide the bundling technology that is used in that project to move source code from a developer's system to the cluster. These plans are still nascent and no work has been done in this area as of yet.

I'm happy to answer any other questions you might have about this project, and thank you for considering it.

[embano1]

I'm not sure if this issue is the right place to ask for the below, so please let me know if I should rather file it in boson-project or somewhere else.

Posting this here since the commands listed by @lance caught me attention as we had a couple of discussions how to easily handle secrets during function creation. From the boson-project docs I understand that there's some support for setting environment variables but no easy way to reference (existing) or create & reference ConfigMaps/Secrets as part of the function creation/deployment step.

There's been some back and forth discussion on whether this is something kn should provide (https://github.com/knative/client/issues/287), but overall I feel kn func would be a better place (at least integrating with Secrets/CMs). Our current users of the VEBA [1] project which deployed VEBA with OpenFaaS like the faas-cli secret command as part of their function creation workflow.

Any thoughts on your end if/how to have a tighter CM/Secret integration in the function authoring workflow with kn func?

[1] https://vmweventbroker.io/

[lance]

I'm not sure if this issue is the right place to ask for the below, so please let me know if I should rather file it in boson-project or somewhere else.

Since opening this issue, I have opened up the Discussions feature on boson-project/func: https://github.com/boson-project/func/discussions. No traffic yet, but community discussion can happen there if it makes sense.

Any thoughts on your end if/how to have a tighter CM/Secret integration in the function authoring workflow with kn func?

@embano1 yes! That is on our existing roadmap. Design work and some planning around this have already happened internally, but we of course would be interested in what the community has to say about this. I will look into starting a thread on our discussion board around this subject.

[zroubalik]

@embano1 the Secrets are tracked here: https://github.com/boson-project/func/issues/362 Feel free to add any suggestions.

[evankanderson]

Note that this will also need to follow:

https://github.com/knative/community/blob/main/REPOSITORY-GUIDELINES.md#requirements-for-repository-donation

The Technical Oversight Committee may allow repositories to be donated to the Knative project. In addition to meeting the core repository requirements, donated repositories must:

• Adopt the Google CLA bot.
• All contributors to the donated repository must have signed the Google CLA.
• All code must adopt the standard Knative header, attributing copyright as follows: "Copyright The Knative Authors".
• Additions of the standard Knative header to code created by the contributors can occur post-transfer, but should ideally occur shortly thereafter.
• An AUTHORS file should be created in the repo root, if one does not already exist, that includes the original authors of the code. See knative/serving AUTHORS for reference.
  • Note that copyright notices should only be modified or removed by the people or organizations named in the notice.

[rhuss]

I added a

- [ ] If the new repository is a code donation check that the donated code meets the [formal requirements for code donations](https://github.com/knative/community/blob/main/REPOSITORY-GUIDELINES.md#requirements-for-repository-donation)

to the checklist above, but wonder now whether we should pick this up for the issue template itself, too ?

[evankanderson]

An overview / argument for plug-points: Plugin argument

A more detailed writeup of the current plugin points: guide to current Boson extensibility

[julz]

My only remaining hesitation I think (and apologies for being a pain), before creating the repo, is I think there’s quite a lot of context and decisions here that it’d be good to write up in a doc in feature track proposal format (given this is a relatively big feature proposal, really, even if it happens to be shipped as a cli plugin to begin with), if only so we have context on some of the decisions that were already taken here.

I think it’d be a nice document to have, and a good opportunity for questions as a community to get us all on the same page and up to speed before embarking on this. To be clear Im totally cool personally if this is a really short doc and if it skips any sections that don't feel relevant, it'd just be nice imo to have an official artifact as a community.

Maybe we could do that doc, have like 1 week or 2 for comments and then do this?

[lance]

@evankanderson et al - reading through the checklist, it seems that a new repo is created during this process. Is there a process by which we can retain the existing code history, issues and pull requests (e.g. simply transfer the repo)?

[markusthoemmes]

Yes, the checklist assumes a template via sample-controller, but we can just as well just move your code over as well no problem.

[evankanderson]

Yes, before we turn on branch protection we can push an existing git repo and history.

[evankanderson]

Feature Track document here.

[csantanapr]

The new git repo was created https://github.com/knative-sandbox/kn-plugin-func /close

[knative-prow-robot]

@csantanapr: Closing this issue.

In response to [this](https://github.com/knative/community/issues/613#issuecomment-994232796): >The new git repo was created https://github.com/knative-sandbox/kn-plugin-func >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.