Browse Source

more doc related cleanup and infra

pull/1289/head
Ross McFarland 4 months ago
parent
commit
73d956954a
No known key found for this signature in database GPG Key ID: 943B179E15D3B22A
8 changed files with 196 additions and 177 deletions
  1. +2
    -1
      docs/source/api.rst
  2. +1
    -1
      docs/source/api/provider-yaml.rst
  3. +5
    -0
      docs/source/api/provider.rst
  4. +5
    -0
      docs/source/api/source.rst
  5. +4
    -4
      docs/source/auto_arpa.md
  6. +10
    -7
      docs/source/configuration.rst
  7. +164
    -164
      octodns/provider/yaml.py
  8. +5
    -0
      octodns/source/base.py

+ 2
- 1
docs/source/api.rst View File

@ -7,5 +7,6 @@ Developer Interface
.. toctree::
:maxdepth: 1
:glob:
/api/yaml-provider.rst
/api/*

docs/source/api/yaml-provider.rst → docs/source/api/provider-yaml.rst View File


+ 5
- 0
docs/source/api/provider.rst View File

@ -0,0 +1,5 @@
Provider
========
.. automodule:: octodns.provider.base
:inherited-members:

+ 5
- 0
docs/source/api/source.rst View File

@ -0,0 +1,5 @@
Source
======
.. automodule:: octodns.source.base
:inherited-members:

+ 4
- 4
docs/source/auto_arpa.md View File

@ -1,4 +1,4 @@
# Automatic PTR Generation With auto_arpa
# Automatic PTR Generation
octoDNS supports the automatic generation of `PTR` records for in-addr.arpa. and ip6.arpa. zones. In order to enable the functionality the `auto_arpa` key needs to be passed to the manager configuration.
@ -48,7 +48,7 @@ In order to add `PTR` records for a zone the `auto-arpa` source should be added
The above will add `PTR` records for any `A` records previously seen with IP addresses 10.0.0.*.
## A Complete Example
## Example
### config/octodns.yaml
@ -102,11 +102,11 @@ fileserver:
* 102.0.0.10: exxampled.com.
* 103.0.0.10: email.exxampled.com., fileserver.exxampled.com.
## Notes
## Complete picture
Automatic `PTR` generation requires a "complete" picture of records and thus cannot be done during partial syncs. Thus syncing `arpa.` zones will throw an error any time filtering of zones, targets, or sources is being done.
### AutoArpa and Dynamic Zone Config
## AutoArpa and Dynamic Zone Config
The AutoArpa provider works with Dynamic Zone Config, but only in the sense that it doesn't stop it from working. It requires another provider to actually generate the list of zones. It could be the Yaml provider like so:


+ 10
- 7
docs/source/configuration.rst View File

@ -7,11 +7,14 @@ Basics
This document picks up where :doc:`getting-started` and :doc:`records` leave off,
discussing details and less common scenarios.
:doc:`api/yaml-provider` lays out the options for configuring the most commonly
YamlProvider
------------
:doc:`api/provider-yaml` lays out the options for configuring the most commonly
used source of record data.
Static Zone Config
..................
------------------
In cases where finer grained control is desired and the configuration of
individual zones varies ``zones`` can be an explicit list with each configured
@ -66,7 +69,7 @@ where zones share config, but not records.::
- ns1
General Configuration Concepts
..............................
------------------------------
``class`` is a special key that tells octoDNS what python class should be
loaded. Any other keys will be passed as configuration values to that
@ -88,7 +91,7 @@ The ``max_workers`` key in the ``manager`` section of the config enables threadi
to parallelize the planning portion of the sync.
``lenient``
...........
-----------
``lenient`` mostly focuses on the details of ``Record``s and standards
compliance. When set to ``true`` octoDNS will allow non-compliant
@ -102,7 +105,7 @@ configured.
.. _Lenience: records.rst#lenience
``strict_supports``
...................
-------------------
``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
@ -124,7 +127,7 @@ set ``strict_supports=false`` on a per provider basis to request that things war
and continue in a best-effort fashion.
Configuring ``strict_supports``
*******************************
...............................
The ``strict_supports`` parameter is available on all providers and can be
configured in YAML as follows::
@ -136,7 +139,7 @@ configured in YAML as follows::
strict_supports: true
Automatic PTR generation
........................
------------------------
octoDNS supports automatically generating PTR records from the ``A``/``AAAA``
records it manages. For more information see the :doc:`auto_arpa`


+ 164
- 164
octodns/provider/yaml.py View File

@ -1,4 +1,168 @@
#
'''
Example Configuration
---------------------
Core provider for records configured in yaml files on disk::
config:
class: octodns.provider.yaml.YamlProvider
# The location of yaml config files. By default records are defined in a
# file named for the zone in this directory, the zone file, e.g.
# something.com.yaml.
# (required)
directory: ./config
# The ttl to use for records when not specified in the data
# (optional, default 3600)
default_ttl: 3600
# Whether or not to enforce sorting order when loading yaml
# (optional, default True)
enforce_order: true
# What sort mode to employ when enforcing order
# - simple: `sort`
# - natural: https://pypi.org/project/natsort/
# (optional, default natural)
order_mode: natural
# Whether duplicate records should replace rather than error
# (optional, default False)
populate_should_replace: false
# The file extension used when loading split style zones, Null means
# disabled. When enabled the provider will search for zone records split
# across multiple YAML files in the directory with split_extension
# appended to the zone name, See "Split Details" below.
# split_extension should include the "."
# (optional, default null, "." is the recommended best practice when
# enabling)
split_extension: null
# When writing YAML records out to disk with split_extension enabled
# each record is written out into its own file with .yaml appended to
# the name of the record. The two exceptions are for the root and
# wildcard nodes. These records are written into a file named
# `$[zone.name].yaml`. If you would prefer this catchall file not be
# used `split_catchall` can be set to False to instead write those
# records out to `.yaml` and `*.yaml` respectively. Note that some
# operating systems may not allow files with those names.
# (optional, default True)
split_catchall: true
# Optional filename with record data to be included in all zones
# populated by this provider. Has no effect when used as a target.
# (optional, default null)
shared_filename: null
# Disable loading of the zone .yaml files.
# (optional, default False)
disable_zonefile: false
# Whether or not ; in values, e.g. TXT, need to be escaped \\;
# (optional, default True)
escaped_semicolons: True
.. Note::
When using this provider as a target any existing comments or formatting in
the zone files will be lost when changes are applyed.
Split Details
-------------
All files are stored in a subdirectory matching the name of the zone
(including the trailing .) of the directory config. It is a recommended
best practice that the files be named RECORD.yaml, but all files are
sourced and processed ignoring the filenames so it is up to you how to
organize them.
With `split_extension: .` the directory structure for the zone github.com.
managed under directory "zones/" would look like::
zones/
github.com./
$github.com.yaml
www.yaml
...
Overriding Values
-----------------
Overriding values can be accomplished using multiple yaml providers in the
`sources` list where subsequent providers have `populate_should_replace`
set to `true`. An example use of this would be a zone that you want to push
to external DNS providers and internally, but you want to modify some of
the records in the internal version.
config/octodns.com.yaml::
---
other:
type: A
values:
- 192.30.252.115
- 192.30.252.116
www:
type: A
values:
- 192.30.252.113
- 192.30.252.114
internal/octodns.com.yaml::
---
'www':
type: A
values:
- 10.0.0.12
- 10.0.0.13
external.yaml::
---
providers:
config:
class: octodns.provider.yaml.YamlProvider
directory: ./config
zones:
octodns.com.:
sources:
- config
targets:
- route53
internal.yaml::
---
providers:
config:
class: octodns.provider.yaml.YamlProvider
directory: ./config
internal:
class: octodns.provider.yaml.YamlProvider
directory: ./internal
populate_should_replace: true
zones:
octodns.com.:
sources:
- config
- internal
targets:
- pdns
You can then sync our records eternally with `--config-file=external.yaml`
and internally (with the custom overrides) with
`--config-file=internal.yaml`
'''
#
#
@ -15,170 +179,6 @@ from .base import BaseProvider
class YamlProvider(BaseProvider):
'''
Example Configuration
---------------------
Core provider for records configured in yaml files on disk.::
config:
class: octodns.provider.yaml.YamlProvider
# The location of yaml config files. By default records are defined in a
# file named for the zone in this directory, the zone file, e.g.
# something.com.yaml.
# (required)
directory: ./config
# The ttl to use for records when not specified in the data
# (optional, default 3600)
default_ttl: 3600
# Whether or not to enforce sorting order when loading yaml
# (optional, default True)
enforce_order: true
# What sort mode to employ when enforcing order
# - simple: `sort`
# - natural: https://pypi.org/project/natsort/
# (optional, default natural)
order_mode: natural
# Whether duplicate records should replace rather than error
# (optional, default False)
populate_should_replace: false
# The file extension used when loading split style zones, Null means
# disabled. When enabled the provider will search for zone records split
# across multiple YAML files in the directory with split_extension
# appended to the zone name, See "Split Details" below.
# split_extension should include the "."
# (optional, default null, "." is the recommended best practice when
# enabling)
split_extension: null
# When writing YAML records out to disk with split_extension enabled
# each record is written out into its own file with .yaml appended to
# the name of the record. The two exceptions are for the root and
# wildcard nodes. These records are written into a file named
# `$[zone.name].yaml`. If you would prefer this catchall file not be
# used `split_catchall` can be set to False to instead write those
# records out to `.yaml` and `*.yaml` respectively. Note that some
# operating systems may not allow files with those names.
# (optional, default True)
split_catchall: true
# Optional filename with record data to be included in all zones
# populated by this provider. Has no effect when used as a target.
# (optional, default null)
shared_filename: null
# Disable loading of the zone .yaml files.
# (optional, default False)
disable_zonefile: false
# Whether or not ; in values, e.g. TXT, need to be escaped \\;
# (optional, default True)
escaped_semicolons: True
.. Note::
When using this provider as a target any existing comments or formatting in
the zone files will be lost when changes are applyed.
Split Details
-------------
All files are stored in a subdirectory matching the name of the zone
(including the trailing .) of the directory config. It is a recommended
best practice that the files be named RECORD.yaml, but all files are
sourced and processed ignoring the filenames so it is up to you how to
organize them.
With `split_extension: .` the directory structure for the zone github.com.
managed under directory "zones/" would look like::
zones/
github.com./
$github.com.yaml
www.yaml
...
Overriding Values
-----------------
Overriding values can be accomplished using multiple yaml providers in the
`sources` list where subsequent providers have `populate_should_replace`
set to `true`. An example use of this would be a zone that you want to push
to external DNS providers and internally, but you want to modify some of
the records in the internal version.
config/octodns.com.yaml::
---
other:
type: A
values:
- 192.30.252.115
- 192.30.252.116
www:
type: A
values:
- 192.30.252.113
- 192.30.252.114
internal/octodns.com.yaml::
---
'www':
type: A
values:
- 10.0.0.12
- 10.0.0.13
external.yaml::
---
providers:
config:
class: octodns.provider.yaml.YamlProvider
directory: ./config
zones:
octodns.com.:
sources:
- config
targets:
- route53
internal.yaml::
---
providers:
config:
class: octodns.provider.yaml.YamlProvider
directory: ./config
internal:
class: octodns.provider.yaml.YamlProvider
directory: ./internal
populate_should_replace: true
zones:
octodns.com.:
sources:
- config
- internal
targets:
- pdns
You can then sync our records eternally with `--config-file=external.yaml`
and internally (with the custom overrides) with
`--config-file=internal.yaml`
'''
SUPPORTS_GEO = True
SUPPORTS_DYNAMIC = True
SUPPORTS_POOL_VALUE_STATUS = True


+ 5
- 0
octodns/source/base.py View File

@ -10,6 +10,11 @@ class BaseSource(object):
SUPPORTS_DYNAMIC_SUBNETS = False
def __init__(self, id):
'''
:param id: unique identifier for the provider or source
:type id: str
'''
self.id = id
if not getattr(self, 'log', False):
raise NotImplementedError(


Loading…
Cancel
Save