Wondered if this might get more traction in here, ...
# dotnet
s
Wondered if this might get more traction in here, since it's a dotnetty question
b
this https://www.pulumi.com/docs/reference/pkg/azure-native/authorization/getroledefinition/#getroledefinition says that
scope
is a required input So I think the better question is, why does your first example work? lol
s
because getRoleDefinition and RoleDefinition.Get don't seem to be the same thing! I kind of assumed that this was secret Pulumi knowledge that everyone knew...
My current solution uses the old Azure package to get the role definition, then the new Azure Native one to actually assign it. Which is kind of neat in a "using multiple packages together seamlessly" way, but probably not what the Pulumi devs want to see
Copy code
using System.Threading.Tasks;
using Pulumi;
using Azure = Pulumi.AzureNative;
using AzureAD = Pulumi.AzureAD;
using OldAzure = Pulumi.Azure;

class MyStack : ComponentResource
{
    public MyStack()
    {
        var rg = new Azure.Resources.ResourceGroup("rg", new Azure.Resources.ResourceGroupArgs
        {
            Location = "UK South"
        });

        var contributorRoleDef = Output.Create(OldAzure.Authorization.GetRoleDefinition.InvokeAsync(new OldAzure.Authorization.GetRoleDefinitionArgs
        {
            Name = "Contributor"
        }));

        var globalAdmins = Output.Create(AzureAD.GetGroup.InvokeAsync(new AzureAD.GetGroupArgs
        {
            Name = "Global Admins"
        }));

        var assignment1 = new Azure.Authorization.RoleAssignment("assignment1", new Azure.Authorization.RoleAssignmentArgs
        {
            PrincipalId      = globalAdmins.Apply(grp => grp.Id),
            RoleDefinitionId = contributorRoleDef.Apply(def => def.Id),
            Scope            = rg.Id,
            PrincipalType    = "Group"
        });
    }
}
t
Hi @salmon-egg-38815 The native Azure provider also has getRoleDefinition: https://www.pulumi.com/docs/reference/pkg/azure-native/authorization/getroledefinition/ It’s a bit harder to use because the ARM API isn’t as nice as the old provider’s data source.
Note that
RoleDefinition.Get
and
GetRoleDefinition
aren’t the same thing.
Also, you have to invoke any of them inside an
Apply
because you are trying to pass an output as an argument.
Mixing two providers is fine too
Finally, here is an example that is similar to what you need with a workaround of calling Azure API directly: https://github.com/pulumi/examples/blob/master/azure-cs-call-azure-api/
👍 2
s
Thanks for the example~, although I was hoping for a bit more "value add" from an IaC solution!~ 😄 This isn't the place for moaning though. I think I'll stick with the old provider until the new one matures a bit I did a bit more reading on the point of the native provider, so it makes sense that it's only as good as the underlying Azure API.
t
Yes, that’s our design choice with pros and cons. A ton of internal MS tools rely on the same API and API specs so we expect them to be good for all new features and services. Some older stuff isn’t perfect though. We may start amending some critical bits later on. With read-only operations, we can’t possibly provide users with all combinations of queries they may need, so we provide a way to integrate Azure SDKs into Pulumi programs. Unfortunately, the .NET Azure SDK isn’t great yet (especially, the cross-platform one).
👍 2