mirror/github-octodns
1
0
Fork 0
mirror of https://github.com/github/octodns.git synced 2024-05-11 05:55:00 +00:00
Code Issues Releases Activity

Pass at copy editing the new strict_supports documentation

Browse Source
This commit is contained in:
Ross McFarland
2021-08-31 15:07:59 -07:00
parent a40641edaa
commit 816d54f3d0
2 changed files with 7 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
CHANGELOG.md
View File

@@ -5,10 +5,10 @@
* Provider `strict_supports` param added, currently defaults to `false`, along
with Provider._process_desired_zone this forms the foundations of a new
"supports" system where providers will warn or error (depending on the value
of `strict_supports` during planning about their inability to do what they're
being asked. When `false` they will warn and "adjust" the desired records.
When true they will abort with an error indicating the problem. Over time it
is expected that all "supports" checking/handling will move into this
of `strict_supports`) during planning about their inability to do what
they're being asked. When `false` they will warn and "adjust" the desired
records. When true they will abort with an error indicating the problem. Over
time it is expected that all "supports" checking/handling will move into this
paradigm and `strict_supports` will likely be changed to default to `true`.
* Zone shallow copy support, reworking of Processors (alpha) semantics
* NS1 NA target now includes `SX` and `UM`. If `NA` continent is in use in

6
README.md
View File

@@ -232,15 +232,15 @@ The above command pulled the existing data out of Route53 and placed the results
### `lenient`
`lenient` mostly focuses on the details of `Record`s and standards compliance. When set to `true` will octoDNS will allow allow non-compliant configurations & values when possible. For example CNAME values that don't end with a `.`, label length restrictions, or invalid geo codes on `dynamic` records. When in lenient mode octoDNS will log validation problems at `WARNING` and try and continue with the configuration or source data as it exists to the degree possible. See [Lenience](/docs/records.md#lenience) for more information on the concept and how it can be configured.
`lenient` mostly focuses on the details of `Record`s and standards compliance. When set to `true` octoDNS will allow allow non-compliant configurations & values where possible. For example CNAME values that don't end with a `.`, label length restrictions, and invalid geo codes on `dynamic` records. When in lenient mode octoDNS will log validation problems at `WARNING` and try and continue with the configuration or source data as it exists. See [Lenience](/docs/records.md#lenience) for more information on the concept and how it can be configured.
### `strict_supports` (Work In Progress)
`strict_supports` is a `Provider` level parameter that comes into play when a provider has been asked to create a record that it is unable to support. The simplest case of this would be record type, e.g. `SSHFP` not being supported by `AzureProvider`. If such a record is passed to an `AzureProvider` as a target the provider will take action based on the `strict_supports`. When `true` it will throw an exception saying that it's unable to create the record, when set to `false` it will log at `WARNING` with information about what it's unable to do and how it is attempting to working around it. Other examples of things that cannot be supported would be `dynamic` records on a provider that only supports simple or the lack of support for specific geos in a provider, e.g. Route53Provider does not support `NA-CA-*`.
It is worth noting that these errors will happen during the plan phase of things so that problems will be indicated without having to make changes.
It is worth noting that these errors will happen during the plan phase of things so that problems will be visible without having to make changes.
This concept is currently a work in progress and partially implemented. While work is on-going `strict_supports` will defaults to `false`. Once the work is considered complete & ready the default will change to `true` as it's a much safer and less surprising default as what you configure is what you'll get unless an error is throw telling you why it cannot be done. You will then have the choice to explicitly request that things continue with a work-around. In the meantime it is encouraged that you manually configure the parameter to `true` in your provider configs.
This concept is currently a work in progress and only partially implemented. While work is on-going `strict_supports` will default to `false`. Once the work is considered complete & ready the default will change to `true` as it's a much safer and less surprising default as what you configure is what you'll get unless an error is throw telling you why it cannot be done. You will then have the choice to explicitly request that things continue with work-arounds with `strict_supports` set to false`. In the meantime it is encouraged that you manually configure the parameter to `true` in your provider configs.
### Configuring `strict_supports`