[New Repo] knative-sandbox/func-go

[lance]

Repo information

Org: knative-sandbox

Repo: func-go

Purpose (Description): This is the function invocation and runtime framework for Go functions. Currently this framework is applied and built using a custom buildpack for Knative Go functions. The motivation to move this framework to its own repository is driven by many things.

• Eliminates the need to maintain a function-specific buildpack in https://github.com/boson-project/packs
• Allows us to default to the paketo golang buildpack alone, and for users to use any go-capable buildpack they want
• Enables on-cluster builds for Go functions, which is currently prevented by limitations in the Tekton task related to specifying - additional buildpacks
• Enables s2i builds for Go functions, as the framework is now simply a library dependency instead of being applied in the buildpack (eventually - awaiting a fix from golang s2i maintainers)
• Enables the function developer to run the function locally without requiring a container image and docker daemon
  Makes the function invocation mechanism for Go functions more transparent/open for greater potential community input

Sponsoring WG: Functions

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.

• 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.

• Ask Steering to add the repo to EasyCLA in Slack. https://jira.linuxfoundation.org/plugins/servlet/desk/portal/4/SUPPORT-14819

• (golang) Send a PR to add aliases for knative.dev/$REPONAME import paths (sample). process(new-repo): add redirects for knative.dev/runtime docs#5363

• Have a lead from the sponsoring WG bootstrap the Git repository: https://github.com/knative-sandbox/func-go

• Add your GitHub ID to the OWNERS file for your repo: https://github.com/knative-sandbox/func-go/blob/bdb689ab48fdfa682888d58a3d73aae310748dad/OWNERS#L1

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

Note that this repo currently exists (with a single commit) at: https://github.com/lance/func-go

[psschwei]

Are you thinking of doing similar repos for other languages, e.g. func-python, func-node, func-cobol ... ?

[lance]

Are you thinking of doing similar repos for other languages, e.g. func-python, func-node, func-cobol ... ?

The other runtimes all have frameworks that they use which are not maintained within the knative/knative-sandbox orgs. For example boson-project/faas-js-runtime and boson-project/parliament. I did not have any real intention of moving those here, as there is no real demand for it and it doesn't buy us anything (other than perhaps more eyeballs, which is arguably a good thing).

The motivation for moving the golang framework here is that it really does need to be separated from the buildpack itself to enable any go-capable buildpack to work (or s2i) or some other build strategy we have not enabled yet. The invocation framework should not be hidden within a builder (and likely duplicated to other potential builders), but instead be declared as a dependency on the function. That's the primary motivation for the change. Ideally, I'd like the package to be a part of knative.dev as there really is not much use for it outside of the project.

I suppose it's odd that I am not proposing to move the other frameworks here. I'd be willing to discuss it for sure. I seem to recall some opposition to that when we first donated the project. I could be misremembering, so I'm open to revisiting the idea.

[dsimansk]

Would it make sense to create a monorepo of sort to cover for the future expansion maybe?

E.g. knative.dev/func-runtimes/go is still a nice import path. :)

[lance]

Would it make sense to create a monorepo of sort to cover for the future expansion maybe?

E.g. knative.dev/func-runtimes/go is still a nice import path. :)

Sure I am OK with that too. I think probably we could still keep the import path as knative.dev/runtime with a redirect from github.com/knative-sandbox/func-runtimes/go.

[psschwei]

I suppose it's odd that I am not proposing to move the other frameworks here. I'd be willing to discuss it for sure. I seem to recall some opposition to that when we first donated the project. I could be misremembering, so I'm open to revisiting the idea.

No issues from with just moving the go framework, just wasn't sure if this was something go-specific or part one of a larger migration you had planned (though I probably could've figured that out if I had clicked on the buildpack link before commenting 😄).

I also like the monorepo idea. edit: TOC discussion brought up reasons why monorepo might not be good (see below)

[evankanderson]

It was brought up that git tagging for versions might be better if we had per-language libraries.

[evankanderson]

We probably also want these to be library-semver-versioned, rather than Knative-service versioned.

[lance]

We probably also want these to be library-semver-versioned, rather than Knative-service versioned.

@evankanderson if we forego the Knative versioning, what elements of Prow, hack, etc. should we include in this repo? Are there recommended practices for the Knative org to manage versioning for small sub-projects like this, beyond repository tags and the like? I have been a big fan of release-please in other, smaller projects and this might work well for module versioning, tagging and changelog here. OTOH, if there are Knative-recommended ways of handling these things outside of the standard Prow based workflow, I'm happy to adopt those as well.

[zroubalik]

Wouldn't be func-go-runtime a better name?

By seeing func-go one could get the impression that it is some kind of go version of func.

[lance]

@zroubalik if we end up moving Node.js and Python runtimes to knative-sandbox as func-node and func-python maybe that will help clarify?

[zroubalik]

@lance I think it will bring more confusion 😄 I would think that these repos are node and python implementations of func not the runtime.

The best name would be imho func-runtime-go, func-runtime-node,...

[dprotaso]

@lance is this still in progress?

[lance]

We are using https://github.com/knative-extensions/func-go - I think this can be closed. Thanks for the ping @dprotaso