You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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.
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)
Hello!
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:
Get
functionality is undocumented (it doesn't appear here: https://www.pulumi.com/registry/packages/pulumiservice/api-docs/)Team.Get
/Stack.Get
vsGetTeam.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
The text was updated successfully, but these errors were encountered: