Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use of k8s.io namespace for API group in Kubernetes CRDs needs approval #552

Closed
trisberg opened this issue Jan 21, 2020 · 4 comments
Closed
Assignees
Labels
breaking-change enhancement New feature or request
Milestone

Comments

@trisberg
Copy link

trisberg commented Jan 21, 2020

In order to use k8s.io namespace in the API group for CRDs KEDA would need to have approval and add an "api-approved.kubernetes.io" annotation - see kubernetes/enhancements#1111

One option is to change the API group to use a domain like keda.sh that is owned by the project.

Expected Behavior

KEDA CRDs conform to the Kubernetes API Review Process

Actual Behavior

The KEDA CRDs deployed to Kubernetes v1.16.0 and later have the following failed status condition:

  - lastTransitionTime: "2020-01-21T15:22:05Z"
    message: protected groups must have approval annotation "api-approved.kubernetes.io",
      see https://github.com/kubernetes/enhancements/pull/1111
    reason: MissingAnnotation
    status: "False"
    type: KubernetesAPIApprovalPolicyConformant

Steps to Reproduce the Problem

  1. Deploy the KEDA CRDs to a Kubernetes v1.16.x cluster
  2. Check the status condition KubernetesAPIApprovalPolicyConformant of the CRDs using kubectl describe crd/scaledobjects.keda.k8s.io

Specifications

  • Version: v1.0
  • Platform: Kubernetes v1.16 and later
  • Scaler(s):
@scothis
Copy link

scothis commented Jan 21, 2020

While a breaking change, I'd suggest renaming the api group from keda.k8s.io to keda.sh

@tomkerkhove tomkerkhove added this to the v2.0 milestone Jan 23, 2020
@tomkerkhove
Copy link
Member

Good point, thanks. We're adding this to our v2.0 release!

@tomkerkhove
Copy link
Member

I was thinking this through a bit more and what if we:

  1. Introduce new CRDs in v1.2 under keda.sh
  2. Remove current CRD in v2.0

That way we are already moving towards the new approach, but don't have to rush a 2.0 release until we bundle it with more breaking changes.

Would that be ok for you or do you think this should be fixed ASAP?

/cc @jeffhollan @ahmelsayed

@tomkerkhove tomkerkhove added breaking-change enhancement New feature or request and removed bug Something isn't working labels Mar 31, 2020
@tomkerkhove tomkerkhove modified the milestone: v2.0 Mar 31, 2020
@zroubalik
Copy link
Member

merged into v2 branch

@zroubalik zroubalik self-assigned this Apr 29, 2020
preflightsiren pushed a commit to preflightsiren/keda that referenced this issue Nov 7, 2021
frozenprocess added a commit to frozenprocess/dashboard that referenced this issue May 13, 2023
* Experimental annotation until we can sort out the approval. kedacore/keda#552
* Url in docs pointing to the right resource
frozenprocess added a commit to frozenprocess/dashboard that referenced this issue May 13, 2023
* Experimental annotation until we can sort out the approval. kedacore/keda#552
* Url in docs pointing to the right resource
k8s-ci-robot pushed a commit to kubernetes/dashboard that referenced this issue May 15, 2023
* Experimental annotation until we can sort out the approval. kedacore/keda#552
* Url in docs pointing to the right resource
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants