From aa9643ecbf7f7f8943d064167bdd010f58b8a479 Mon Sep 17 00:00:00 2001 From: Kevin Paulisse Date: Wed, 27 Feb 2019 08:30:34 -0600 Subject: [PATCH 1/2] Update limitations.md --- doc/limitations.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/limitations.md b/doc/limitations.md index 7049b9ba..946b8f9c 100644 --- a/doc/limitations.md +++ b/doc/limitations.md @@ -2,11 +2,11 @@ Testing of Puppet catalogs is faster than running the agent, but you need to be careful of the following limitations: -0. Facts are not taken from a live agent run +1. Facts are not taken from a live agent run octocatalog-diff by default uses the facts reported from a node's more recent Puppet run. If you have made changes to custom facts, catalog testing will **NOT** be an adequate test of whether your custom facts worked. (You can still use octocatalog-diff to help predict changes to nodes based on changes to facts, by overriding facts on the command line.) -0. Agents handle depenency ordering and implementation details +1. Agents handle depenency ordering and implementation details The catalog defines the state of the system, but it's up to the agent to determine how to bring the system to a point that matches the catalog. The agent is responsible for order of operations and actually making the change. @@ -16,7 +16,7 @@ Testing of Puppet catalogs is faster than running the agent, but you need to be - Operations not supported by the provider. For example, assume that in your current Puppet manifests, you set the size of a file system to 100 GB. You change this in your new branch to 50 GB. octocatalog-diff will dutifully report this change to you. However, the agent will fail to make the change, because it is not possible to shrink a file system from 100 GB to 50 GB. -0. Changes in underlying providers may not be noticed +1. Changes in underlying providers may not be noticed Consider that you are using a Puppet module that creates a file system. The current implementation of that module checks to see if *any* file system is present on the device, and creates a new file system there if no file system was present. You upgrade the module, and the new version checks to see if *the specified* file system is present on the device, and reformats the device with the specified file system (regardless of whether there was no file system or if there was an existing file system of a different type). There would be no catalog changes (hence octocatalog-diff would report nothing) because the catalog simply instructs the agent to create a file system of the specified type at the defined location. However, the actual implementation of those instructions has changed dramatically. From 2f56bacf845b1936c85468b12c00cf450604ff60 Mon Sep 17 00:00:00 2001 From: Kevin Paulisse Date: Wed, 27 Feb 2019 08:31:34 -0600 Subject: [PATCH 2/2] Update limitations.md --- doc/limitations.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/doc/limitations.md b/doc/limitations.md index 946b8f9c..8579a592 100644 --- a/doc/limitations.md +++ b/doc/limitations.md @@ -4,21 +4,21 @@ Testing of Puppet catalogs is faster than running the agent, but you need to be 1. Facts are not taken from a live agent run - octocatalog-diff by default uses the facts reported from a node's more recent Puppet run. If you have made changes to custom facts, catalog testing will **NOT** be an adequate test of whether your custom facts worked. (You can still use octocatalog-diff to help predict changes to nodes based on changes to facts, by overriding facts on the command line.) + octocatalog-diff by default uses the facts reported from a node's more recent Puppet run. If you have made changes to custom facts, catalog testing will **NOT** be an adequate test of whether your custom facts worked. (You can still use octocatalog-diff to help predict changes to nodes based on changes to facts, by overriding facts on the command line.) 1. Agents handle depenency ordering and implementation details - The catalog defines the state of the system, but it's up to the agent to determine how to bring the system to a point that matches the catalog. The agent is responsible for order of operations and actually making the change. + The catalog defines the state of the system, but it's up to the agent to determine how to bring the system to a point that matches the catalog. The agent is responsible for order of operations and actually making the change. - Two specific situations that catalog testing does **NOT** detect are: + Two specific situations that catalog testing does **NOT** detect are: - - Dependency loops (e.g., you have made A require B, B require C, and C require A). + - Dependency loops (e.g., you have made A require B, B require C, and C require A). - - Operations not supported by the provider. For example, assume that in your current Puppet manifests, you set the size of a file system to 100 GB. You change this in your new branch to 50 GB. octocatalog-diff will dutifully report this change to you. However, the agent will fail to make the change, because it is not possible to shrink a file system from 100 GB to 50 GB. + - Operations not supported by the provider. For example, assume that in your current Puppet manifests, you set the size of a file system to 100 GB. You change this in your new branch to 50 GB. octocatalog-diff will dutifully report this change to you. However, the agent will fail to make the change, because it is not possible to shrink a file system from 100 GB to 50 GB. 1. Changes in underlying providers may not be noticed - Consider that you are using a Puppet module that creates a file system. The current implementation of that module checks to see if *any* file system is present on the device, and creates a new file system there if no file system was present. You upgrade the module, and the new version checks to see if *the specified* file system is present on the device, and reformats the device with the specified file system (regardless of whether there was no file system or if there was an existing file system of a different type). There would be no catalog changes (hence octocatalog-diff would report nothing) because the catalog simply instructs the agent to create a file system of the specified type at the defined location. However, the actual implementation of those instructions has changed dramatically. + Consider that you are using a Puppet module that creates a file system. The current implementation of that module checks to see if *any* file system is present on the device, and creates a new file system there if no file system was present. You upgrade the module, and the new version checks to see if *the specified* file system is present on the device, and reformats the device with the specified file system (regardless of whether there was no file system or if there was an existing file system of a different type). There would be no catalog changes (hence octocatalog-diff would report nothing) because the catalog simply instructs the agent to create a file system of the specified type at the defined location. However, the actual implementation of those instructions has changed dramatically. In general catalog testing is great for: