This is a continuation of the previous articles on IaC deployment errors and resolutions. In this section, we talk about in-place edit of resources and their property assignments. When compared to destroy and create, in-place updates of resources are much easier and a relief to deployment supervision because the overall resource behaves the same in relation to its dependencies and those that depend on it. These attributes can include a wide variety from version to rules or features but the address, binding and contract remain somewhat the same as earlier. In-place edits must have a corresponding IaC change. One of the common errors with in-place edits is that what’s feasible via the management portal, SDK or CLI may not be available in the IaC directives. For example, a restart of a resource does not necessarily have a corresponding directive. Another example as with an example of popular Azure App Service is when the access restrictions turn the public access on or off. In both cases, the access restriction remains set. Sometimes this can be overridden by simply adding a rule to allow an ip address which in turn automatically adds a deny all to other source ip addresses. The behavior can have equivalence but does not come with independent directives in the IaC syntax and semantics.

Another example of when in-place edits is not always predefined is when the value is generated. For example, a public ip address resource when deployed by the IaC might yield one ip address when run the first time and another when run subsequently. If the address determines the connectivity to the resource, the client trying to access the resource by the ip address must be changed twice. In such a case, it might be prudent to separate the updates to the resource that goes together with the generation of an ip address and create an ip address for re-purposable assignment beforehand. In those cases, the clients don’t need to change.

A tthird example of in-place edits that are counter-intuitive is when we want to make the changes that can be masked as an in-place edit so that other resources do not need to know. For example, a group of resources can be edited in place without impact to others. All it would take is to treat  a resource and its dependencies as a unit so that even if one requires the other to be informed of the change, the overall update appears in-place to the rest of the deployment.

Another example of an in-place edit is a DNS zone record update to a different ip address. In reality the ‘@’ record is the top-level record of its type for that subdomain represented in the DNS zone and changing its value is essentially assigning the same name to a different resource. In these cases, the client that used to communicate by ip address might no longer be getting the same resource and even iif it is using the same name might not be able to tell the difference when one resource is used instead of the other.

Some of the pitfalls of in-place edits is when the visibility is lost or the changes remain hidden to the deployment and the idempotency is lost because the operations are no longer stateless. Such is the case with an application gateway when the updates to a backend pool member might require the removal and repeat addition of the pool member so that the application gateway can refresh its awareness of that member. In these cases, one might rely on the start/stop behavior rather than actually making these part of the IaC.

These are some of the extended examples of the in-place edits. Thank you for staying tuned.