Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
---
2023-06-02 21:41:36 -07:00
title_tag: "replaceOnChanges | Resource Options"
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
meta_desc: The replaceOnChanges resource option indicates that changes to properties on a resource should force a replacement instead of an in-place update.
2023-05-15 15:25:28 -07:00
title: "replaceOnChanges"
h1: "Resource option: replaceOnChanges"
2023-06-08 16:15:52 -07:00
meta_image: /images/docs/meta-images/docs-meta.png
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
menu:
2023-05-15 15:25:28 -07:00
concepts:
2022-01-25 12:51:43 -08:00
identifier: replaceOnChanges
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
parent: options
2023-09-22 18:32:40 -07:00
weight: 13
2023-05-15 15:25:28 -07:00
aliases:
- /docs/intro/concepts/resources/options/replaceonchanges/
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
---
The `replaceOnChanges` resource option can be used to indicate that changes to certain properties on a resource should force a replacement of the resource instead of an in-place update. Typically users rely on the resource provider to make this decision based on whether the input property is one that the provider knows how to update in place, or if not, requires a replacement to modify. However, there are cases where users want to replace a resource on a change to an input property even if the resource provider itself doesn't believe it has to replace the resource.
For example, with Kubernetes `CustomResource` resources, the Kubernetes resource model doesn't know whether or not a specific input property on a specific kind of `CustomResource` requires a replacement, and so assumes that *any* change can be made without replacement. However, in practice, many specific kinds of `CustomResource` in the Kubernetes ecosystem *do* require replacement when certain input properties are changed. The Kubernetes provider itself can't know this, but users can use `replaceOnChanges` to ensure that these changes can be made correctly via Pulumi.
2022-05-03 21:23:32 -07:00
{{< chooser language " javascript , typescript , python , go , csharp , java , yaml " > }}
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% choosable language javascript %}}
```javascript
let widget = new k8s.apiextensions.CustomResource("widget", {
apiVersion: 'acmecorp.com/v1alpha1',
kind: 'Widget',
spec: {
input: "something",
},
}, { replaceOnChanges: ["spec.input"] });
```
{{% /choosable %}}
{{% choosable language typescript %}}
```typescript
let widget = new k8s.apiextensions.CustomResource("widget", {
apiVersion: 'acmecorp.com/v1alpha1',
kind: 'Widget',
spec: {
input: "something",
},
}, { replaceOnChanges: ["spec.input"] });
```
{{% /choosable %}}
{{% choosable language python %}}
```python
widget = apiextensions.CustomResource("widget",
api_version="acmecorp.com/v1alpha1",
kind="Widget",
spec={
"input": "something",
},
opts=ResourceOptions(replace_on_changes=["spec.input"])
)
```
{{% /choosable %}}
{{% choosable language go %}}
```go
widget, err = apiextensions.NewCustomResource(ctx, "widgt", & apiextensions.CustomResourceArgs{
ApiVersion: pulumi.String("acmecorp.com/v1alpha1"),
Kind: pulumi.String("Widget"),
OtherFields: kubernetes.UntypedArgs{
"spec": map[string]interface{}{
"input": "something",
},
},
}, pulumi.ReplaceOnChanges([]string{"spec.input"})
```
{{% /choosable %}}
{{% choosable language csharp %}}
```csharp
var widget = new Pulumi.Kubernetes.ApiExtensions.CustomResource("widget", new WidgetArgs
{
Spec = new WidgetSpecArgs
{
Input = "something",
}
2023-07-07 01:45:14 +02:00
},
new CustomResourceOptions
{
ReplaceOnChanges = { "spec.input" },
});
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
```
2022-05-03 21:23:32 -07:00
{{% /choosable %}}
{{% choosable language java %}}
```java
var widget = new com.pulumi.kubernetes.apiextensions.CustomResource("widget",
WidgetArgs.builder()
.spec(WidgetSpecArgs.builder()
.input("something")
.build())
.build(),
CustomResourceOptions.builder()
.replaceOnChanges("spec.input")
.build());
```
{{% /choosable %}}
{{% choosable language yaml %}}
```yaml
# YAML doesn't support kubernetes:apiextensions.k8s.io:CustomResource
# See https://github.com/pulumi/pulumi-yaml/issues/161 for details.
```
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% /choosable %}}
{{< / chooser > }}
The property paths provided as input to `replaceOnChanges` can each describe a subset of the properties of the resource which should trigger a replacement on changes. The `*` wildcard can be used in any part of a path. A few examples of what changes will trigger replacement for a given property path string are:
- `*` : any property change
- `spec` : any change to the `spec` property or any of its children
- `spec[0]` : any change to the first element of the array in the `spec` property or any of its children
2023-08-05 16:52:22 -04:00
- `spec[*].item` : any change to the `item` property of any element of the array in the `spec` property or any of the `item` property's children
Break Resource page into separate pages for each core concept (#938)
Even after breaking the Programming Model content down, this Resources page still contained a *lot* of core content. This made a lot of important features feel very "hidden", like resource options, components, dynamic providers, and more.
It also led to suboptimal search results, both in Google and in our own internal site search, because searches for specific concepts (like "pulumi aliases") would return the "Resources" page, which didn't even rank particularly well as it doesn't "feel" like definitive content for this specific topic.
This change breaks this page into 18 separate pages. It keeps the "Custom Resource" content in the main Resources page (since that content is nearly entirely actually not specific to Custom Resources anyway), pulls the Custom Resource, Resource Providers and Dynamic Providers content into separate top level items, and pulls the Resource Options content into it's own index with a separate page per resource option.
Some of the resulting pages are fairly light in content, but this actually offers room to flesh these out more fully now that they have room to breathe.
Reading through this content as part of the refactor, there is quite a bit of cleanup we could still do here. I took a few liberties to clean up some things as part of this, but mostly focused on the refactor instead of changes to prose.
This also introduces a set of client-side redirects to the resources page, so that each of the previous anchors which now lives elsewhere will get redirected in the client, following the same strategy used in the Programming Model page refactor.
2022-01-17 17:49:07 -08:00
{{% notes "info" %}}
The property paths passed to `replaceOnChanges` should always be the "camelCase" version of the property name, as used in the core Pulumi resource model.
{{% /notes %}}
If there are initialization errors on a resource (because the resource was created but failed to fully initialize correctly on a previous deployment) then the resource will normally be updated on the following Pulumi update, even if there are no other changes to the resource's inputs. If `*` is specified as a property path for `replaceOnChanges` , then initialization errors will trigger a replacement instead of an update.
2023-05-15 15:25:28 -07:00
The `replaceOnChanges` resource option can be combined with the [`deleteBeforeReplace` ](/docs/concepts/options/deletebeforereplace ) resource option to trigger a resource to be deleted before it is replaced whenever a given input has changes.
2022-06-23 14:58:15 -04:00
{{% notes type="warning" %}}
The `replaceOnChanges` resource option does not apply to component resources, and will not have the intended effect.
{{% /notes %}}