Flux v2 naming proposal

[stefanprodan]

Outline

As we approach feature parity with Flux & Helm Operator v1, we've come to the conclusion, based on community feedback, that the "GitOps Toolkit" naming is confusing to Flux users and newcomers.

We picked the toolkit name because it was an experiment at the time (April '20) to build a Flux like, extendable, component based solution (for which the "toolkit" name was fitting). As the experiment grew, the toolkit became a collection of Go packages, APIs, Kubernetes controllers, Kubernetes manifests and a CLI.

Going forward we want to have a clear distinction between Flux (the thing you install and operate) and the GitOps Toolkit (tools you use to build software that extends Flux).

Proposal

Flux lives in fluxcd/flux2 repository and, as the name implies, is the next major version of fluxcd/flux. Flux v2 is built with the GitOps Toolkit SDK and comes with its own command-line utility called flux.

The fluxcd/flux2 repository is the centrepiece from where we do releases and provide support, it contains:

• the flux CLI source code
• install manifests (bundles all server-side components)
• addon manifests (monitoring stack, policies, etc)
• end-to-end testing of the bundled components and CLI

The GitOps Toolkit is a SDK for building Kubernetes controllers that can interact with Flux to extend its functionality.

Naming

Item	Old Name	New Name
Repository	fluxcd/toolkit	fluxcd/flux2
CLI	gotk	flux
System namespace	gotk-system	flux-system
Repository	fluxcd/fluxcd.io	fluxcd/website
Docs Website	toolkit.fluxcd.io	fluxcd.io/docs
User Guides	toolkit.fluxcd.io/guides	fluxcd.io/docs/flux
Dev Guides	toolkit.fluxcd.io/dev-guides	fluxcd.io/docs/gitops-toolkit

[monadic]

+1

[shanesveller]

As a downstream user who is not likely to contribute at the code level (no Golang affinity/experience worth mentioning), I don't have any strong reactions to the current or proposed naming schemes, but would like to see a decision reached so that you folks have closure and can spend energy elsewhere. Most of the ramifications don't seem to affect end-users enough for our votes to carry much weight - AFAICT they're mostly about the project's "meta" health around lineage/discovery/marketing, which is of course understandable to keep an eye on. I'll maybe just have some find-and-replace to do on existing work, but that's no harm done and the price of being an early adopter.

[allymparker]

Awesome, thanks folks, now I don't need to say "goh-t-kuh" ;) Any ideas of timeframes?

[stefanprodan]

We will discuss the proposal in tomorrow's dev meeting. If there are no objections we'll start with the toolkit repo/cli rename. The fluxcd.io website changes will take some time but I don't think it should block the CLI rename.

[phillebaba]

I think it is great that we can make a decision for a name that (hopefully) sticks. I agree that using the flux brand is the best move, as it may reduce confusion from existing users and people on the outside looking in. It is important that we are able to convert the existing "old" flux users to fluxv2, it would be a shame if they switched to something else due to a naming confusion.

I have some small comments on the naming, as I don't want to replicate the confusion that exists today with AngularJS vs Angular2 vs Angular4.

Calling the CLI flux is nice and short, but may confuse people who come across fluxctl. Its easy for an outsider to be confused, especially if they are installing it with some package manager.

We should probably redirect or add a notice to docs.fluxcd.io to show that its the old docs and the new docs are located under fluxcd.io/docs.

TLDR; +1

[hiddeco]

Calling the CLI flux is nice and short, but may confuse people who come across fluxctl. Its easy for an outsider to be confused, especially if they are installing it with some package manager.

We will archive the fluxcd/flux repository once the support window ends, and direct people towards the new repository. This also applies to package managers like Homebrew, where we will show a deprecation note.

We should probably redirect or add a notice to docs.fluxcd.io to show that its the old docs and the new docs are located under fluxcd.io/docs.

The fluxcd.io will likely show a notice that it is the website for the new Flux (in the same style as the current notification about the GitOps Toolkit), while the old website will do the opposite.

[phillebaba]

Great! In that case I am onboard with the change 💯

[seaneagan]

any impact on the domain names used by the CRDs?

[squaremo]

I think it would be fine to leave these as they are. I don't think they are very visible, and in any case, there's no great opportunity for confusion. wdyr?

[stefanprodan]

I think the CRD group is fine as it is, we don't want to remove the toolkit subdomain to get back to the HelmRelease conflict.

[hiddeco]

To add to this, I think the APIs are part of the SDK (even if they are end-user facing in the end), so the toolkit prefix makes sense.

[scottrigby]

I think this will make it much clearer for new people users joining the Flux community 👏 👏 great work on this

[stefanprodan]

The renaming progress can be tracked here #388

[scottrigby]

📣 Update: The Flux community now has a defined decision making and proposal process, as part of its new Governance.

This proposal has been accepted through consensus by the Oversight Committee, after wider community input here as well as in public Flux dev meetings.

I believe… this is the first Flux proposal accepted since the new Governance decision making guidelines 😄 👏 Great work everyone!