Proposal to donate Kf into Knative

[gganpaa]

Objective

Google proposes to donate Kf to the Knative project.

Background

We’ve been working with a number of customers on their journey to adopt Knative, and have consistently heard strong feedback from CF developers who want to leverage their existing understanding and “developer interface” with Knative.

While the Kn tool provides a great experience for deploying containers, many developers are looking for a source-to-URL experience without needing to think about containers at all.

Kf is a migration tool which helps developers transition from a Cloud Foundry (CF) environment to a Knative and Kubernetes-based environment. Kf enables a migration story for CF apps to transition to Knative while teams build in-house operational expertise to manage Knative and Kubernetes components directly.

Kf builds on the experiences provided by the Kn CLI, which is already a part of Knative, to provide an experience familiar to CF developers. Kf is designed to help teams transition into using Knative and Kn, and should not be considered a replacement/alternative CLI to the native Kn tooling.

Current Status

Kf currently supports the cf push developer experience via Buildpacks or Docker images. It also supports CF marketplace and services via the Kubernetes Service Catalog. Kf has the following dependencies:

1. Knative Serving 0.6
2. Knative Build 0.6 (migration to Tekton in progress)
3. Istio 1.1.3
4. Kubernetes Service Catalog 0.2.1

Knative Project Fit

Kf has a strong alignment as a client of the Knative resources. It has and will continue to drive additional requirements into the Knative project, and continue to drive the usage of Knative and the set of use-cases Knative can enable. Many of the customers we’ve worked with are excited about the idea of using Knative through the lens of a cf push style experience and would like to see that a part of the overall Knative story.

Kf does have dependencies beyond Knative, e.g. Service Catalog and Tekton, and requires additional custom CRDs and controllers. Over time we will work to understand the common blocks for Knative and Kf and separate them from Kf client.

We see few main goals aligning with Knative:

1. Provide a CF-to-Knative migration path by building a tool that gives a CF-like developer experience on top of Knative.
2. Create a tight feedback loop between customers and Knative developers to help identify pain-points and prioritize work on the Knative/serving roadmap.
3. Engage with the Knative community (Red Hat, Pivotal, IBM, SAP) to enhance the project and shape the roadmap for Kf.

Future Directions

Kf at the moment is an experimental project creating an opinionated client experience for Knative. It does not and will not replace Kn, nor should it prevent other opinionated experiences from being introduced into the Knative project. We expect to rapidly and continuously improve Kf as we work with more customers and perform more real-world migrations.

We will continue to work with a set of target customers who are migrating from CF to Knative and Kubernetes, to drive the roadmap and requirements for Kf and additional work into the rest of the Knative project as appropriate.

Initial Roadmap

• Support for Buildpacks
• Deploy apps
• Binding services (eg: MySQL)
• Controls such as namespaces, users, quotas
• Service Catalog

Process of donation and adoption

We propose that Kf be spun up as a new workgroup that works closely with the Client WG. The Kf workgroup will focus on delivering the opinionated client experience while driving requirements and roadmap ideas into the Client, Serving, and Observability workgroups.

An initial OWNERS file would list Google, but we expect other names will be added as contributions are accepted.

Donation Checklist

• [x] Original authors/owners decide a donation is appropriate
• [ ] Notification of proposal
  • [x] Submit proposal to knative/community repo
  • [x] Email notification of proposal sent to knative-users and knative-dev
• [ ] Approval of adoption by Knative committees
  • [ ] Steering Committee approval on fit for the Knative project
  • [ ] Technical Oversight Committee approval to adopt the repo/code (as per its charter).
• [ ] Update code licenses
  • [ ] Apache License 2.0 applied to code
  • [ ] Creative Commons License 4.0 applied to documentation
• [ ] Relocate the repository
  • [ ] Create OWNERS file
  • [ ] Create AUTHORS file
  • [ ] Update copyright header to Copyright (C) 2019 The Knative Authors.
  • [ ] Verify that all contributors are Google CLA signatories
  • [ ] Adopt Google CLA bot

[duglin]

Any plans to make the Kf features into kn plugins? I think having 2 community driven CLIs will confuse people.

[bsnchan]

I'm curious if you've considered moving Kf to the CFF given that the tool does provide a CF-like experience on top of Knative?

[gganpaa]

@duglin The Kf CLI is built for (a) CF users who want to adopt Knative and (b) for the tools that integrate into CF’s workflow (eg: CI/CD tools, scripts), with the goal to provide CF like experience. If there is common functionality suitable for all Knative users, we will work with the kn client working group to get that included in kn. For example, the opinionated push command would not make sense to be part of kn, but a logs command might.

[gganpaa]

@bsnchan We did consider CFF. Customers who we have worked with are excited about the idea of using Knative with cf push style experience. Ultimately, we see Kf as a tool to onboard CF users to Knative. CFF doesn’t feel like the right place for something with this scope.

[rgregg]

Closing this out since we were unable to reach a consensus.