Updated Frequently Asked Questions (markdown)

Frequently-Asked-Questions.md

@@ -3,6 +3,7 @@
 * [Why Can't I Connect a Virtual Circuit to an Interface?](#why-cant-i-connect-a-virtual-circuit-to-an-interface)
 * [How Can I Add New Interface Types?](#how-can-i-add-new-interface-types)
 * [Why Does NetBox Support Only Image Attachments?](#user-content-why-does-netbox-support-only-image-attachments)
+* [Why Aren't Device Type Component Modifications Retroactive?](#user-content-why-arent-device-type-component-modifications-retroactive)
 
 # Why Doesn't NetBox Scan for IPs?
 
@@ -54,4 +55,14 @@ The set of available interface types (previously referred to as "form factors" i
 
 NetBox supports the attachment of images to certain models, namely sites, racks, and devices. This feature was added as a convenience to provide readily-accessible photographic documentation of installations. For instance, a data center technician might opt to upload a close-up photo of a device and its connections to clarify where each named interface resides on the box.
 
-While NetBox might seem like an ideal place to store additional documents (PDFs, configurations, etc.), these are best maintained with the rest of your network's static documentation in a dedicated file store with appropriate access controls and revision history. Although other files cannot be uploaded to NetBox, you can link to them from NetBox in the comments section of an object, or within a custom URL field. Feature request [#969](https://github.com/digitalocean/netbox/issues/969) (currently a work in progress) will make this approach easier by introducing support for templatized URLs to external resources.
+While NetBox might seem like an ideal place to store additional documents (PDFs, configurations, etc.), these are best maintained with the rest of your network's static documentation in a dedicated file store with appropriate access controls and revision history. Although other files cannot be uploaded to NetBox, you can link to them from NetBox in the comments section of an object, or within a custom URL field. Feature request [#969](https://github.com/digitalocean/netbox/issues/969) (currently a work in progress) will make this approach easier by introducing support for templatized URLs to external resources.
+
+# Why Aren't Device Type Component Modifications Retroactive?
+
+NetBox uses device types to define the physical characteristics of a device, including the components installed within it (console ports, interfaces, etc.). When a new device is created, any component templates defined on the device type are automatically populated on the new device, reducing the work needed to model new devices. However, this automation occurs only when a device is first created: Adding or removing components on a device type does _not_ automatically remove or add them to device instances.
+
+This is because automatically removing components requires NetBox to make very dangerous assumptions. For example, suppose you had a device type which included some interfaces on an optional module. After creating some devices, you decided these interfaces shouldn't be created automatically anymore, because new devices were no longer being deployed with that module installed. If NetBox were to automatically delete these interfaces from _all_ devices of this type, it would result in many interfaces being deleted erroneously.
+
+There's a similar issue when attempting to _add_ components automatically. Say you had created a number of devices from an incomplete device type (perhaps they're missing a few interfaces), then you create the missing components on the device type. If NetBox were to populate these components automatically on the existing device instances, it would risk colliding with any components that had already been added to the devices. This would force us to either trigger an error, and prevent the new component templates from being added to the device type, or to ignore the collision, possibly resulting in an unexpected state (e.g. the device components may have been created with incorrect or missing data).
+
+To avoid these problems, NetBox simply leaves it to the user to determine how best to rectify potential discrepancies. Once a device type has been updated, its device instances can easily have components added or removed in bulk. This approach ensures that all changes are driven by intent rather than by assumptions.