feature request: allow importing by alias

[jpo-tu]

Currently, opslevel resources that support importing require specifying the opslevel uid. But a few examples:

opslevel_repository:

terraform import opslevel_repository.example Z2lkOi8vb3BzbGV2ZWwvUmVwb3NpdG9yaWVzOjpHaXRodWIvMVQ0OTAz

opslevel_service:

terraform import opslevel_service.example Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS84Mg

opslevel_team:

terraform import opslevel_team.example Z2lkOi8vb3BzbGV2ZWwvVGVhbS8xODkxOB

In some case a combination of uids is required and it's unclear what the individual uids represent. Examples:

opslevel_service_repository:

terraform import opslevel_service_repository.example Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS84Mg:Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS82MDI0

(I presume Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS84Mg is a service id. But what does Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS82MDI0 represent? By trial and error it is NOT the repository id as you might expect.)

opslevel_service_tool:

terraform import opslevel_service_tool.example Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS84Mg:Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS82MDI0

(What does Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS82MDI0 represent?)

---

These opaque ids are typically only discoverable by inspecting the graphql API response for the respective object, or by looking into existing terraform state if available.

This is a feature request for first-class support for importing via aliases. Hypothetical examples:

terraform import opslevel_service.example my-great-service
terraform import opslevel_team.example team-platform
terraform import opslevel_service_repository.example my-great-service_github.com:my-org/my-great-service-repo

This keeps in the spirit with many other providers that are a joy to import:

s3 bucket (docs):

terraform import aws_s3_bucket.example my-bucket-name

kubernetes namespace (docs):

 terraform import kubernetes_namespace.example my-namespace

github repository (docs):

terraform import github_repository.example my-repo-name

postgresql schema (docs):

$ terraform import postgresql_schema.example my_database.my_schema

Context: We are having to write code/scripts to lookup opslevel uids in order to generate terraform import {} blocks when trying to bring existing infrastructure into terraform or moving state between terraform stacks. The aliases for these resources are known but we cannot use them directly.

[rocktavious]

Thanks for the suggestions @jpo-tu - This is definitely on our minds - unfortunately not every resource in our API is able to be looked up by an alias so we'd end up in some world where some resources can be imported by alias and some cannot. We'd even get into a world where something like opslevel_service_repository would need 1 alias and 1 id 🤮

Fortunately for that resource we might beable to work around that by using the "repo key" which is what your example was my-great-service_github.com:my-org/my-great-service-repo - but we'd end up having to query and iterate through ALL a customers repos to find a match and for some of our customers this would create significant call API burden.

Additionally depending on what other changes are going on in your OpsLevel account - lookup by alias can actually target different resources between API calls (say someone was deleting an alias on something and then adding it to another thing). Aliases are not stable from one API call to another.

So the approach was taken to use the only thing we can safely lookup every resource type by in a stable way - id.

One thing you can do is use the opslevel CLI to dump out import statements opslevel export terraform -h. One word of caution is this command is outdated for Terraform 1.X but we plan to fix it by Jan 31st 2025 to match Terraform 1.X syntax. But it should be safe for the terraform import ... statements it dumps out.

I will also take this as a feature request to in the future have that export command write out terraform import blocks in addition to a bash script with terraform import ... commands.

For now I will put this request in our backlog but because of the above reasons it will not beable to be prioritized untill sometime in 2025.