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.

Sign up for GitHub

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

Jump to bottom

KCC can't acquire ownership of existing folder #147

Closed
Scorpiion opened this issue Apr 16, 2020 · 5 comments
Closed

KCC can't acquire ownership of existing folder #147

Scorpiion opened this issue Apr 16, 2020 · 5 comments
Labels
bug Something isn't working

Comments

@Scorpiion
Copy link

Describe the bug
I reinstall by KCC cluster just now and during that I removed old resources in the old KCC (KCC only, not underlying GCP resources) and then I'm now "reacquiring" those resources in a new installation of KCC by running kubectl apply -f xxx.yaml on the files one by one. When I try to apply a KCC config for folders it does not work, I get this error:

  status:
    conditions:
    - lastTransitionTime: "2020-04-16T12:22:15Z"
      message: 'Update call failed: error applying desired state: Error creating folder
        ''xxxxxxxxxxxx'' in ''folders/xxxxxxxxxxx'': Error waiting for creating
        folder: Error code 9, message: The folder operation violates display name
        uniqueness within the parent.'
      reason: UpdateFailed
      status: "False"
      type: Ready

I also tried to create a new folder in the UI and then to acquire that one, but it also fails like this:

  status:
    conditions:
    - lastTransitionTime: "2020-04-16T12:28:49Z"
      message: 'Update call failed: error applying desired state: Error creating folder
        ''test-folder'' in ''folders/xxxxxxxxxxxxx'': Error waiting for creating folder:
        Error code 9, message: The folder operation violates display name uniqueness
        within the parent.'
      reason: UpdateFailed
      status: "False"
      type: Ready

ConfigConnector Version
Run the following command to get the current ConfigConnector version

1.7.1

To Reproduce
Steps to reproduce the behavior:

  1. Create new folder in the UI

YAML snippets:

# Top level namespace used for folders
apiVersion: v1
kind: Namespace
metadata:
  name: global-resources
  annotations:
    cnrm.cloud.google.com/folder-id: "xxxxxxxx" # Folder where subfolders are created
    cnrm.cloud.google.com/project-id: xxxxxxxxxxxx # Project id of project where the config connector is running

---

apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: Folder
metadata:
  namespace: global-resources
  name: test-folder
  annotations:
    cnrm.cloud.google.com/deletion-policy: abandon # Don't delete GCP resource if KCC entry is deleted
spec:
  displayName: test-folder
@Scorpiion Scorpiion added the bug Something isn't working label Apr 16, 2020
@jcanseco
Copy link
Member

Hi @Scorpiion. Folder resources currently don't support acquisition since their identifiers are generated on server-side upon resource creation. This is in contrast to most KCC resources like SpannerInstance whose identifiers are user-configured. However, we plan to investigate how we can support acquisition of resources with server-generated identifiers in the future.

@Scorpiion
Copy link
Author

Hi @jcanseco, thanks for the clarification. Has there been any updates on this?

I just reinstalled KCC and tried to acquire existing resources and run into this again. I think this is a problem that might not show up in smaller tests and development scenarios but that quickly can become common for production usage. It feels like a bit bad to have to comment out resources that no longer works just because I reinstalled KCC.

@AlexBulankou
Copy link
Contributor

@Scorpiion , one way an existing folder can be acquired today is by specifying numeric folder id in the status field. (You can obtain the numeric id of the folder by listing it using gcloud resource-manager folders list).

For example:

apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: Folder
metadata:
  annotations:
    cnrm.cloud.google.com/organization-id: "[organization_id]"
    cnrm.cloud.google.com/deletion-policy: abandon
  name: [folder_name]
spec:
  displayName: [folder_name]
status:
  name: folders/[folder_numeric_id]

@maqiuyujoyce
Copy link
Collaborator

Hi @Scorpiion , we just released Config Connector v1.32.0, which supports the resource acquisition for Folder via the resourceID field. Now, instead of configuring the status, you can do:

apiVersion: resourcemanager.cnrm.cloud.google.com/v1beta1
kind: Folder
metadata:
  annotations:
    cnrm.cloud.google.com/organization-id: "[organization_id]"
    cnrm.cloud.google.com/deletion-policy: abandon
  name: [folder_name_in_cluster]
spec:
  resourceID: [folder_numeric_id]
  displayName: [folder_display_name]

Detailed documentation will be coming soon.

@maqiuyujoyce
Copy link
Collaborator

Detailed documentation about the new resourceID field: https://cloud.google.com/config-connector/docs/how-to/managing-resources-with-resource-ids

I'm closing the bug for now. @Scorpiion please let us know if you run into any issues using this feature.

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

No branches or pull requests
4 participants
@Scorpiion @jcanseco @AlexBulankou @maqiuyujoyce