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

SDK doesn't expose all API functionality #441

Open
baughj opened this issue Nov 13, 2024 · 1 comment
Open

SDK doesn't expose all API functionality #441

baughj opened this issue Nov 13, 2024 · 1 comment
Labels
kind/enhancement Improvements or new features

Comments

@baughj
Copy link

baughj commented Nov 13, 2024

Hello!

  • Vote on this issue by adding a 👍 reaction
  • If you want to implement this feature, comment to let us know (we'll work with you on design, scheduling, etc.)

Issue details

Thanks for your work on this provider, I fully intend to manage my Pulumi with Pulumi. 😄

Related to pulumi/pulumi-cloud-requests#459 I am trying to write a C# Pulumi program to automatically coalesce permissions on stacks and teams to a known state.

A few things I've noticed about this provider:

  1. as far as I can tell, the Get functionality is undocumented (it doesn't appear here: https://www.pulumi.com/registry/packages/pulumiservice/api-docs/)
  2. The patterns of this provider don't seem to match others - eg Team.Get / Stack.Get vs GetTeam.Invoke/InvokeAsync, GetStack.Invoke/InvokeAsync similar to how the ec2 provider(s) works - I am wondering, generally speaking, if there is a shape or pattern to be followed for providers (we are thinking about writing our own)?

The reason I am opening this issue: There is no interface to the list functionality provided by the Pulumi API (such as list users, list teams, list stacks) In order to maintain permissions on stacks it would be very helpful to be able to have an interface to list them. As it is now, I have to use RestSharp to fetch these things separately instead, which is not great.

My expectation as a user is that the SDK exposes interfaces to all of the routes documented here. Not having an interface for all of the API leads to a really bad experience because you end up having to store the Pulumi API token separately from the stack itself so it can be used by whatever library you're using to talk to the API. I believe there is no way to retrieve a secret as a raw string so you either store it separately or are forced to do really gross things with Apply().

Affected area/feature

Data retrieval from Pulumi Cloud / interface to API

@baughj baughj added kind/enhancement Improvements or new features needs-triage Needs attention from the triage team labels Nov 13, 2024
@cleverguy25 cleverguy25 removed the needs-triage Needs attention from the triage team label Nov 15, 2024
@IaroslavTitov
Copy link
Contributor

Good afternoon, thank you for opening the issue!

  1. I see what you mean, PSP's resources like Team don't have docs on Get, like this. These docs are auto-generated, so likely there's something wrong with generation settings, or provider SDK is outdated, I will take a look.
  2. The SDK is auto-generated as well, so likely the issue is the same as with docs - PSP needs to be migrated to newer pulumi-go-provider, which has been part of the plan for a while, but hasn't happened yet. I hope to get it done in the next couple sprints, but I sadly can't guarantee it.

For list logic, we would need to bring Invokes into PSP, which is another change that was deferred for a long time. Both should be addressed as part of the PSPV1 plan, which I am putting together now to be worked on in the next few sprints.

For the last part, I'm probably misunderstanding, but couldn't you just use a code snippet like below to grab your PAT, stored as a secret?

var plaintextPAT: string
config.requireSecret("pat").apply(secret => plaintext = secret)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement Improvements or new features
Projects
None yet
Development

No branches or pull requests

3 participants