Publish olmv1 kubectl plugin

[ankitathomas]

Publish a new release of the olmv1 kubectl plugin to krew from the operator-controller repo by:

• Tagging and cutting a new release, and publishing a new tar.gz archive for the kubectl plugin
• Adding a krew manifest
• Submit the krew manifest to the krew-index repository

See https://krew.sigs.k8s.io/docs/developer-guide/distributing-with-krew/

[joelanford]

The entire release and krew index update can heppen automatically: https://github.com/operator-framework/kubectl-operator/blob/main/.github/workflows/release.yml

We need to decide as a community what we want the new name of the plugin to be in the krew index. I expect that to be a semi-contentious topic.

[joelanford]

Also, we should consider the versioning implications of putting this binary in this repository because this repository is now at major version 1.

I know that we have said in our public API docs that the CLIs here are not part of the public API, but the reason that mostly works is because users aren't really expected to interact with the CLIs.

In the case of the kubectl plugin, users are expected to interact with the CLI, which leads to:

• it being a pretty tough sell to say "the kubectl plugin is not part of the public API of this project"
• but we're not even close to ready to say "the kubectl plugin CLI is stable"

[ankitathomas]

The entire release and krew index update can heppen automatically: https://github.com/operator-framework/kubectl-operator/blob/main/.github/workflows/release.yml

I wasn't aware we have a workflow in place for publishing to krew, we should hold off on that at least until we finalize what the cli looks like.

is there also a pipeline that publishes kubectl-operator to opensuse somehow?
https://build.opensuse.org/package/show/devel:kubic/kubectl-operator

Apart from that, I don't find too many places directly using kubectl-operator that we may need to get in touch with; just console using it to list operands (which we don't have support for in the olmv1 cli as of now) and a few demos from the github.com/redhat-na-ssa org

There's also the extension_developer_e2e tests like @joelanford mentioned in the demo/docs issue where it makes sense to use the new cli

operator-controller/test/extension-developer-e2e/extension_developer_test.go

Lines 40 to 199 in a6de9f9

	catalog := &ocv1.ClusterCatalog{
	ObjectMeta: metav1.ObjectMeta{
	GenerateName: "catalog",
	},
	Spec: ocv1.ClusterCatalogSpec{
	Source: ocv1.CatalogSource{
	Type: ocv1.SourceTypeImage,
	Image: &ocv1.ImageSource{
	Ref: os.Getenv("CATALOG_IMG"),
	},
	},
	},
	}
	require.NoError(t, c.Create(context.Background(), catalog))
	installNamespace := "default"
	sa := &corev1.ServiceAccount{
	ObjectMeta: metav1.ObjectMeta{
	Name: fmt.Sprintf("serviceaccount-%s", rand.String(8)),
	Namespace: installNamespace,
	},
	}
	require.NoError(t, c.Create(ctx, sa))
	clusterExtension := &ocv1.ClusterExtension{
	ObjectMeta: metav1.ObjectMeta{
	Name: "registryv1",
	},
	Spec: ocv1.ClusterExtensionSpec{
	Source: ocv1.SourceConfig{
	SourceType: "Catalog",
	Catalog: &ocv1.CatalogFilter{
	PackageName: os.Getenv("REG_PKG_NAME"),
	},
	},
	Namespace: installNamespace,
	ServiceAccount: ocv1.ServiceAccountReference{
	Name: sa.Name,
	},
	},
	}
	cr := &rbacv1.ClusterRole{
	ObjectMeta: metav1.ObjectMeta{
	Name: fmt.Sprintf("clusterrole-%s", rand.String(8)),
	},
	Rules: []rbacv1.PolicyRule{
	{
	APIGroups: []string{
	"olm.operatorframework.io",
	},
	Resources: []string{
	"clusterextensions/finalizers",
	},
	Verbs: []string{
	"update",
	},
	ResourceNames: []string{clusterExtension.Name},
	},
	{
	APIGroups: []string{
	"",
	},
	Resources: []string{
	"configmaps",
	"services",
	"serviceaccounts",
	},
	Verbs: []string{
	"create",
	"update",
	"delete",
	"patch",
	"get",
	"list",
	"watch",
	},
	},
	{
	APIGroups: []string{
	"apiextensions.k8s.io",
	},
	Resources: []string{
	"customresourcedefinitions",
	},
	Verbs: []string{
	"create",
	"update",
	"delete",
	"patch",
	"get",
	"list",
	"watch",
	},
	},
	{
	APIGroups: []string{
	"apps",
	},
	Resources: []string{
	"deployments",
	},
	Verbs: []string{
	"create",
	"update",
	"delete",
	"patch",
	"get",
	"list",
	"watch",
	},
	},
	{
	APIGroups: []string{
	"rbac.authorization.k8s.io",
	},
	Resources: []string{
	"clusterroles",
	"roles",
	"clusterrolebindings",
	"rolebindings",
	},
	Verbs: []string{
	"create",
	"update",
	"delete",
	"patch",
	"get",
	"list",
	"watch",
	"bind",
	"escalate",
	},
	},
	},
	}
	require.NoError(t, c.Create(ctx, cr))
	crb := &rbacv1.ClusterRoleBinding{
	ObjectMeta: metav1.ObjectMeta{
	Name: fmt.Sprintf("clusterrolebinding-%s", rand.String(8)),
	},
	Subjects: []rbacv1.Subject{
	{
	Kind: "ServiceAccount",
	Name: sa.Name,
	Namespace: sa.Namespace,
	},
	},
	RoleRef: rbacv1.RoleRef{
	APIGroup: "rbac.authorization.k8s.io",
	Kind: "ClusterRole",
	Name: cr.Name,
	},
	}
	require.NoError(t, c.Create(ctx, crb))
	t.Logf("When creating an ClusterExtension that references a package with a %q bundle type", clusterExtension.ObjectMeta.Name)
	require.NoError(t, c.Create(context.Background(), clusterExtension))

[github-actions]

Issues go stale after 90 days of inactivity. If there is no further activity, the issue will be closed in another 30 days.