search

crossplane-contrib / provider-equinix-metal

DEPRECATED: Use provider-jet-equinix :warning:
https://github.com/crossplane-contrib/provider-jet-equinix
Apache License 2.0
16 stars 8 forks source link

Friendly project name vs. uuid? #4

Closed prasek closed 4 years ago

prasek commented 5 years ago

Is there an option to use the friendly project name vs. UUID?

image

image

//cc @hasheddan

prasek commented 5 years ago

I know the project can be renamed, UUIDs are stable, and you can easily get the UUID from the project settings, but the rest of the fields in this are human readable, so the project_id is the only field that isn't human readable. Maybe this is more of an issue for Packet itself, if they supported GCP-style project ids this would work with that.

jasmingacic commented 5 years ago

@prasek What you are suggesting really makes sense. I can certainly pass this and see what can be done.

hasheddan commented 5 years ago

@prasek @jasmingacic one options could also be to have the Provider scoped to a certain project. We follow this pattern in stack-gcp and I think it would make sense here as well.

displague commented 4 years ago

Thanks for reporting this @prasek !

I'm actually running into the same need in other tools. One complication with presenting project names is that the project names can overlap between organizations. I've encountered this with projects named "Dev", for example, across numerous Packet organizations my account is a member of.

That said, I'm closing this because (like @hasheddan suggested) v0.0.2 moved the ProjectID into the Provider (and also made it configurable through the provider secret as a fall-back).

https://gist.github.com/displague/cbed973ce8925fa94c8db1250c5deae9#file-0-packet-provider-yaml

Additionally, the latest Device resource shape does not include the ProjectID:

https://gist.github.com/displague/cbed973ce8925fa94c8db1250c5deae9#file-1-packet-device-yaml