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

No events are raised when creating a project AccessToken resource #107

Open
jeremyj563 opened this issue Sep 15, 2023 · 3 comments
Open
Labels
bug Something isn't working

Comments

@jeremyj563
Copy link

What happened?

No Kubernetes events are raised after creating a CR instance of accesstokens.projects.gitlab.crossplane.io. It appears this API was recently implemented with #82

How can we reproduce it?

  • Start watching for events

    selector="\
    involvedObject.apiVersion=projects.gitlab.crossplane.io/v1alpha1,\
    involvedObject.kind=AccessToken,\
    involvedObject.name=example-access-token"
    
    kubectl get events -A --watch-only --field-selector="${selector}"
  • Create CR instance using the v0.4.0 example:

    kubectl apply -f - <<EOF
    apiVersion: projects.gitlab.crossplane.io/v1alpha1
    kind: AccessToken
    metadata:
      name: example-access-token
    spec:
      forProvider:
        accessLevel: 40
        expiresAt: 2024-03-15T08:00:00Z
        name: example-access-token
        projectIdRef:
          name: example-project
        scopes:
          - read_repository
      providerConfigRef:
        name: gitlab-provider
      writeConnectionSecretToRef:
        name: gitlab-example-access-token
        namespace: crossplane-system
    EOF
  • Observe that expected events are never raised

  • Also note that no relevant log messages are produced even when using the --debug argument

What environment did it happen in?

Crossplane version: v1.13.2
Crossplane Provider GitLab version: v0.4.0

  • Cloud provider or hardware configuration: Amazon EC2
  • Kubernetes version (use kubectl version):
    Client Version: v1.28.1
    Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
    Server Version: v1.26.0+k3s1
    
  • Kubernetes distribution (e.g. Tectonic, GKE, OpenShift): k3d
  • OS (e.g. from /etc/os-release):
    NAME="Ubuntu"
    VERSION="20.04.6 LTS (Focal Fossa)"
    ID=ubuntu
    ID_LIKE=debian
    PRETTY_NAME="Ubuntu 20.04.6 LTS"
    VERSION_ID="20.04"
    HOME_URL="https://www.ubuntu.com/"
    SUPPORT_URL="https://help.ubuntu.com/"
    BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
    PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
    VERSION_CODENAME=focal
    UBUNTU_CODENAME=focal
    
  • Kernel (e.g. uname -a)
    Linux ip-10-83-125-214 5.15.0-1043-aws #48~20.04.1-Ubuntu SMP Wed Aug 16 18:26:32 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
    
@jeremyj563 jeremyj563 added the bug Something isn't working label Sep 15, 2023
@MisterMX
Copy link
Collaborator

I tested it with the provided examples on ae5ea6d83e742bf3717f1bec85aaa77db5f8b97c and reconciling works without issues. Events can be seen when I run kubectl describe on the object.

@jeremyj563 Maybe your field selector contains some wrong formatting? I am able to get the events by running

kubectl get events -A -w --field-selector="involvedObject.apiVersion=projects.gitlab.crossplane.io/v1alpha1,involvedObject.kind=AccessToken,involvedObject.name=example-access-token"

@jeremyj563
Copy link
Author

Hi @MisterMX, thanks for looking into it. I'll do some more testing in a bit. Just curious though - was the access token actually created in GitLab?

@MisterMX
Copy link
Collaborator

As this was not part of the issue, I did not test it with a working Gitlab instance, only a plain K8s cluster. Despite that I still received error events that the controller could not connect to Gitlab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants