pulumi-azure-native
pulumi-azure-native copied to clipboard
Updating Apim operation policy leads to no changes
What happened?
when updating an api operation policy with plumi and the policy does not exist this runs well. but when It already exists the policy won't be updated.
Example
var xml = @"
<policies>
<inbound>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>";
var policy = new ApiOperationPolicy($"policy", new ApiOperationPolicyArgs
{
ResourceGroupName = resourceGroupName,
ServiceName = apiManagementServiceName,
ApiId = api.Name,
OperationId = apiOperation.Name,
Value = xml,
Format = "xml",
}, new CustomResourceOptions() { ReplaceOnChanges = { "*" }, DeleteBeforeReplace = true});
Output of plumi after deploying making a change in the xml and deploying again:
Resources:
4 unchanged
Duration: 2s
Output of pulumi about
NAME VERSION Pulumi 3.60.0 Pulumi.AzureNative 2.35.0
Additional context
When this is deployed and you make a change to the XML and deploy it again. The change won't be committed
@vdboots I've just re-created and run your example given above, filling in the missing resources:
using Pulumi;
using Pulumi.AzureNative.Resources;
using System.Collections.Generic;
using Pulumi.AzureNative.ApiManagement;
using Pulumi.AzureNative.ApiManagement.Inputs;
return await Pulumi.Deployment.RunAsync(() =>
{
var resourceGroup = new ResourceGroup("resourceGroup", new ResourceGroupArgs
{
Location = "EastUS"
});
var ams = new ApiManagementService("apim", new ApiManagementServiceArgs
{
ResourceGroupName = resourceGroup.Name,
Location = resourceGroup.Location,
PublisherEmail = "[email protected]",
PublisherName = "Pulumi",
Sku = new ApiManagementServiceSkuPropertiesArgs
{
Capacity = 0,
Name = "Consumption",
},
});
var api = new Api("api", new ApiArgs
{
ResourceGroupName = resourceGroup.Name,
ServiceName = ams.Name,
DisplayName = "My API",
Path = "myapi",
SubscriptionRequired = true,
Protocols = new List<Union<string, Protocol>> { Protocol.Https },
});
var apiOperation = new ApiOperation("operation", new ApiOperationArgs
{
ResourceGroupName = resourceGroup.Name,
ServiceName = ams.Name,
ApiId = api.Name,
DisplayName = "My Operation",
Method = "GET",
UrlTemplate = "operation",
});
var xml = @"
<policies>
<inbound>
</inbound>
<backend>
<base />
</backend>
<outbound>
<base />
</outbound>
<on-error>
<base />
</on-error>
</policies>";
var policy = new ApiOperationPolicy($"policy", new ApiOperationPolicyArgs
{
ResourceGroupName = resourceGroup.Name,
ServiceName = ams.Name,
ApiId = api.Name,
OperationId = apiOperation.Name,
Value = xml,
Format = "xml",
}, new CustomResourceOptions() { ReplaceOnChanges = { "*" }, DeleteBeforeReplace = true });
});
The initial deployment completes correctly, and making a minor change to the XML (e.g. replace <base />
with <base></base>
) results in a replacement as specified by your resource options:
Type Name Status Info
pulumi:pulumi:Stack sdf-dev
+- └─ azure-native:apimanagement:ApiOperationPolicy policy replaced (1s) [diff: ~value]
Resources:
+-1 replaced
5 unchanged
Duration: 8s
Removing the additional resource options and updating the XML also works for me without error:
Type Name Status Info
pulumi:pulumi:Stack sdf-dev
~ └─ azure-native:apimanagement:ApiOperationPolicy policy updated (2s) [diff: ~value]
Resources:
~ 1 updated
5 unchanged
Please elaborate on how to recreate the error you're seeing.
will try it out tommorew it told me the same. But the policy didn't update on azure itself.
@danielrbradley Have you checked if the change was applied on Azure, given the last comment from @vdboots ?
@mikhailshilkov Yes, my change was applied in the Azure portal ... I added the following rules to the <inbound>
section:
<base />
<find-and-replace from="xyz" to="abc" />
What's the change you're actually applying to the policy value @vdboots ?
@danielrbradley On a different machine I tried the same as @vdboots
NAME VERSION Pulumi 3.61.0 Pulumi.AzureNative 2.37.0
Initial deployment went well.
After making a minor change
Resources: 7 unchanged
This is exact the same behaviour as vdboots mentioned.