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

data source | allowedGenerations #158

Open
nhomble opened this issue Jul 31, 2024 · 2 comments
Open

data source | allowedGenerations #158

nhomble opened this issue Jul 31, 2024 · 2 comments

Comments

@nhomble
Copy link

nhomble commented Jul 31, 2024

Problem

Importing existing clusters is difficult with the provider because we may be on older generations, so we are left trying to find the guid for that id.

It would be more effective if we can use something like the channel data resource to give us the generationId for the name.

API Spec

{
  "channels": [
    {
      "allowedGenerations": [
        {
          "name": "string",
          "uuid": "string"
        }
      ],
      "defaultGeneration": {
        "name": "string",
        "uuid": "string"
      },
      "name": "string",
      "uuid": "string"
    }
  ],
  "clusterPlanTypes": [
    {
      "name": "string",
      "uuid": "string"
    }
  ],
  "regions": [
    {
      "backups": [
        {
          "regions": [
            {
              "label": "string",
              "id": "string"
            }
          ],
          "uuid": "string"
        }
      ],
      "name": "string",
      "uuid": "string"
    }
  ]
}
@multani
Copy link
Collaborator

multani commented Aug 1, 2024

@nhomble do you have an example of how you would see it written in HCL?

@nhomble
Copy link
Author

nhomble commented Aug 1, 2024

My first thought is to return a map(string) where the key is the name (which is something I see in the console) and then the value is the guid that we'd use in the actual resources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants