Add validation to improve pep8 check for designate project
This PS will help project avoid pep8 some issues for *.rst in whole project. Co-authored-By: Hoang Trung Hieu <hieuht@vn.fujitsu.com> Change-Id: I7a01863b1aa0bcf999be6e6e2261ab35530c196a
This commit is contained in:
Nguyen Van Trung
parent
64c2609395
commit
154d12114f
@ -78,7 +78,8 @@ Branch, work, & submit:
|
||||
Testing
|
||||
-------
|
||||
|
||||
Execute a single test using py27 (test is CentralServiceTest.test_count_domains)
|
||||
Execute a single test using py27
|
||||
(test is CentralServiceTest.test_count_domains)
|
||||
|
||||
.. code-block:: shell
|
||||
|
||||
|
||||
@ -44,7 +44,7 @@ Response:
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
HTTP/1.1 201 CREATED
|
||||
HTTP/1.1 201 CREATED
|
||||
Content-Type: application/json; charset=UTF-8
|
||||
X-Openstack-Request-Id: req-bfcd0723-624c-4ec2-bbd5-99e985efe8db
|
||||
|
||||
@ -57,7 +57,7 @@ Response:
|
||||
"created_at": "2016-05-20 06:15:42",
|
||||
"updated_at": null,
|
||||
"id": "af91edb5-ede8-453f-af13-feabdd088f9c"
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Now, if someone were to try and create ``foo.example.com.``,
|
||||
|
||||
@ -266,7 +266,8 @@ Update the designate pool manager cache database schema
|
||||
show this help message and exit
|
||||
|
||||
``--revision REVISION``
|
||||
The version that the designate pool manager cache database should be synced to.
|
||||
The version that the designate pool manager cache database
|
||||
should be synced to.
|
||||
(Defaults to latest version)
|
||||
|
||||
|
||||
@ -280,7 +281,8 @@ designate-manage pool_manager_cache version
|
||||
usage: designate-manage pool_manager_cache version [-h]
|
||||
|
||||
|
||||
Show what version of the pool manager cache database schema is currently in place
|
||||
Show what version of the pool manager cache database schema
|
||||
is currently in place
|
||||
|
||||
**Optional arguments:**
|
||||
|
||||
@ -314,7 +316,8 @@ Update the designate powerdns database schema
|
||||
show this help message and exit
|
||||
|
||||
``--revision REVISION``
|
||||
The version that the designate pool manager cache database should be synced to.
|
||||
The version that the designate pool manager cache database
|
||||
should be synced to.
|
||||
(Defaults to latest version)
|
||||
|
||||
|
||||
|
||||
@ -8,9 +8,11 @@ Notifications
|
||||
In this context, "notifications" are not related to the DNS NOTIFY message.
|
||||
|
||||
|
||||
Notifications are RPC calls that contain a JSON object. Designate both generates and receives notifications.
|
||||
Notifications are RPC calls that contain a JSON object.
|
||||
Designate both generates and receives notifications.
|
||||
|
||||
The purpose of notifications in to inform unrelated OpenStack components of events in real time and trigger actions.
|
||||
The purpose of notifications in to inform unrelated OpenStack components
|
||||
of events in real time and trigger actions.
|
||||
|
||||
Emitters
|
||||
--------
|
||||
@ -60,14 +62,18 @@ They are emitted by Central on the following events:
|
||||
Receivers
|
||||
---------
|
||||
|
||||
Notification from other OpenStack component outside of Designate are received by :ref:`designate-sink`.
|
||||
Notification from other OpenStack component outside of Designate are
|
||||
received by :ref:`designate-sink`.
|
||||
|
||||
Format
|
||||
------
|
||||
|
||||
An example notification from Neutron:
|
||||
|
||||
.. literalinclude:: ../../../designate/tests/resources/sample_notifications/neutron/port.delete.start.json
|
||||
.. code-block:: none
|
||||
|
||||
More examples can be found at :file:`designate/tests/resources/sample_notifications`
|
||||
.. literalinclude:: ../../../designate/tests/resources/sample_notifications/neutron/port.delete.start.json
|
||||
|
||||
More examples can be found at
|
||||
:file:`designate/tests/resources/sample_notifications`
|
||||
|
||||
|
||||
@ -26,18 +26,19 @@ You can set an ordered list of filters to run on each zone create api request.
|
||||
We provide a few basic filters below, and creating custom filters follows a
|
||||
similar pattern to schedulers.
|
||||
|
||||
You can create your own by extending :class:`designate.scheduler.filters.base.Filter`
|
||||
You can create your own by extending
|
||||
:class:`designate.scheduler.filters.base.Filter`
|
||||
and registering a new entry point in the ``designate.scheduler.filters``
|
||||
namespace like so in your ``setup.cfg`` file:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
[entry_points]
|
||||
designate.scheduler.filters =
|
||||
my_custom_filter = my_extention.filters.my_custom_filter:MyCustomFilter
|
||||
[entry_points]
|
||||
designate.scheduler.filters =
|
||||
my_custom_filter = my_extention.filters.my_custom_filter:MyCustomFilter
|
||||
|
||||
The new filter can be added to the ``scheduler_filters`` list in the ``[service:central]``
|
||||
section like so:
|
||||
The new filter can be added to the
|
||||
``scheduler_filters`` list in the ``[service:central]`` section like so:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
@ -53,7 +54,8 @@ The filters list is ran from left to right, so if the list is set to:
|
||||
|
||||
scheduler_filters = attribute, random
|
||||
|
||||
There will be two filters ran, the :class:`designate.scheduler.filters.attribute_filter.AttributeFilter`
|
||||
There will be two filters ran,
|
||||
the :class:`designate.scheduler.filters.attribute_filter.AttributeFilter`
|
||||
followed by :class:`designate.scheduler.filters.random_filter.RandomFilter`
|
||||
|
||||
|
||||
|
||||
@ -24,9 +24,9 @@ Overview
|
||||
|
||||
In designate we support the concept of multiple "pools" of DNS Servers.
|
||||
|
||||
This allows operators to scale out their DNS Service by adding more pools, avoiding
|
||||
the scalling problems that some DNS servers have for number of zones, and the total
|
||||
number of records hosted by a single server.
|
||||
This allows operators to scale out their DNS Service by adding more pools,
|
||||
avoiding the scalling problems that some DNS servers have for number of zones,
|
||||
and the total number of records hosted by a single server.
|
||||
|
||||
This also allows providers to have tiers of service (i.e. the difference
|
||||
between GOLD vs SILVER tiers may be the number of DNS Servers, and how they
|
||||
@ -81,7 +81,8 @@ Managing Pools
|
||||
|
||||
In mitaka we moved the method of updating pools to a CLI in `designate-manage`
|
||||
|
||||
There is a YAML file that defines the pool, and is used to load this information into the database.
|
||||
There is a YAML file that defines the pool, and is used to load
|
||||
this information into the database.
|
||||
|
||||
|
||||
.. literalinclude:: ../../../etc/designate/pools.yaml.sample
|
||||
|
||||
@ -65,15 +65,15 @@ both owning different zones, can under the right circumstances inject content
|
||||
into DNS responses for the other tenants zone. Let's consider an example:
|
||||
|
||||
Tenant A owns "example.com.", and has created an additional NS record within
|
||||
their zone pointing to "ns.example.org." Tenant B, the attacker in this example,
|
||||
can now create the "example.org." zone within their tenant. Within this zone,
|
||||
they can legitimately create an A record with the name "ns.example.org.". Under
|
||||
default configurations, many DNS servers (e.g. BIND), will now include Tenant
|
||||
B's A record within responses for several queries for "example.com.". Should
|
||||
the recursive resolver used by the end-user not be configured to ignore
|
||||
out-of-bailiwick responses, this potentially invalid A record for
|
||||
"ns.example.org." will be injected into the resolvers cache, resulting in
|
||||
a cache poisoning attack.
|
||||
their zone pointing to "ns.example.org." Tenant B, the attacker in this
|
||||
example, can now create the "example.org." zone within their tenant. Within
|
||||
this zone, they can legitimately create an A record with the name
|
||||
"ns.example.org.". Under default configurations, many DNS servers (e.g. BIND),
|
||||
will now include Tenant B's A record within responses for several queries
|
||||
for "example.com.". Should the recursive resolver used by the end-user not be
|
||||
configured to ignore out-of-bailiwick responses, this potentially invalid
|
||||
A record for "ns.example.org." will be injected into the resolvers cache,
|
||||
resulting in a cache poisoning attack.
|
||||
|
||||
This is an "interesting variation" of DNS cache poisoning, because the poison
|
||||
records are returned by the authoritative nameserver for a given zone, rather
|
||||
|
||||
@ -37,7 +37,7 @@ Response:
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: application/json; charset=UTF-8
|
||||
X-Openstack-Request-Id: req-bfcd0723-624c-4ec2-bbd5-99e985efe8db
|
||||
|
||||
@ -46,7 +46,7 @@ Response:
|
||||
"recordset_records": 20,
|
||||
"zone_records": 500,
|
||||
"zone_recordsets": 500,
|
||||
"zones": 500
|
||||
"zones": 500
|
||||
}
|
||||
|
||||
Administrators with the ability to use the ``X-Auth-All-Projects`` header
|
||||
@ -68,15 +68,15 @@ Zones
|
||||
Recordsets/Records
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
+------------------+-------------------------------------------------+---------+
|
||||
| Quota | Description | Default |
|
||||
+------------------+-------------------------------------------------+---------+
|
||||
| zone_recordsets | Number of recordsets allowed per zone | 500 |
|
||||
+------------------+-------------------------------------------------+---------+
|
||||
| zone_records | Number of records allowed per zone | 500 |
|
||||
+------------------+-------------------------------------------------+---------+
|
||||
| recordset_records| Number of records allowed per recordset | 20 |
|
||||
+------------------+-------------------------------------------------+---------+
|
||||
+------------------+------------------------------------------+---------+
|
||||
| Quota | Description | Default |
|
||||
+------------------+------------------------------------------+---------+
|
||||
| zone_recordsets | Number of recordsets allowed per zone | 500 |
|
||||
+------------------+------------------------------------------+---------+
|
||||
| zone_records | Number of records allowed per zone | 500 |
|
||||
+------------------+------------------------------------------+---------+
|
||||
| recordset_records| Number of records allowed per recordset | 20 |
|
||||
+------------------+------------------------------------------+---------+
|
||||
|
||||
|
||||
Zone Exports
|
||||
@ -103,10 +103,10 @@ All of the quotas above can be set as a default for all users by editing the
|
||||
########################
|
||||
## General Configuration
|
||||
########################
|
||||
quota_zones = 500
|
||||
quota_zone_recordsets = 500
|
||||
quota_zone_records = 500
|
||||
quota_recordset_records = 20
|
||||
quota_zones = 500
|
||||
quota_zone_recordsets = 500
|
||||
quota_zone_records = 500
|
||||
quota_recordset_records = 20
|
||||
quota_api_export_size = 1000
|
||||
|
||||
Per-Tenant via API
|
||||
@ -133,7 +133,7 @@ The response would be:
|
||||
|
||||
.. code-block:: http
|
||||
|
||||
HTTP/1.1 200 OK
|
||||
HTTP/1.1 200 OK
|
||||
Content-Type: application/json; charset=UTF-8
|
||||
X-Openstack-Request-Id: req-bfcd0723-624c-4ec2-bbd5-99e985efe8db
|
||||
|
||||
@ -142,5 +142,5 @@ The response would be:
|
||||
"recordset_records": 20,
|
||||
"zone_records": 500,
|
||||
"zone_recordsets": 500,
|
||||
"zones": 100
|
||||
}
|
||||
"zones": 100
|
||||
}
|
||||
|
||||
@ -4,17 +4,25 @@ Troubleshooting
|
||||
I have a broken zone
|
||||
--------------------
|
||||
|
||||
A zone is considered broken when it is not receiving updates anymore. Its status can be "ERROR" if Designate detected the error condition or it can be stuck in "PENDING" for a long time.
|
||||
A zone is considered broken when it is not receiving updates anymore.
|
||||
Its status can be "ERROR" if Designate detected the error condition
|
||||
or it can be stuck in "PENDING" for a long time.
|
||||
|
||||
Review the logs from the API, Central, Producer, Worker and MiniDNS.
|
||||
Identify the transaction ID of the last successful change and the first failing change. Using the ID, you can filter logs from the Designate components that are related to the same transaction.
|
||||
Look for log messages with ERROR level before and after the first failing update.
|
||||
Identify the transaction ID of the last successful change and the first
|
||||
failing change. Using the ID, you can filter logs from the Designate
|
||||
components that are related to the same transaction.
|
||||
Look for log messages with ERROR level before and after
|
||||
the first failing update.
|
||||
|
||||
Failures in updating a zone are usually related to problems in Producer, Worker, MiniDNS or the database.
|
||||
Failures in updating a zone are usually related to problems in Producer,
|
||||
Worker, MiniDNS or the database.
|
||||
|
||||
Ensure the services are running and network connectivity is not impaired.
|
||||
|
||||
Transient network issues can be the cause of a broken zone. Producer and Worker are stateful services and perform attempts at restoring failing zones over time. Restarting the services will trigger new attempts.
|
||||
Transient network issues can be the cause of a broken zone.
|
||||
Producer and Worker are stateful services and perform attempts at restoring
|
||||
failing zones over time. Restarting the services will trigger new attempts.
|
||||
|
||||
|
||||
I have a broken pool
|
||||
@ -23,7 +31,8 @@ I have a broken pool
|
||||
I deleted a zone but it's still in the database
|
||||
-----------------------------------------------
|
||||
|
||||
Deleted zones are flagged with "status" set to "DELETED" and "task" set to "NONE" once the deletion process terminates successfully.
|
||||
Deleted zones are flagged with "status" set to "DELETED" and "task" set to
|
||||
"NONE" once the deletion process terminates successfully.
|
||||
|
||||
What ports should be open?
|
||||
--------------------------
|
||||
@ -66,7 +75,8 @@ The default values are:
|
||||
What network protocol are used?
|
||||
-------------------------------
|
||||
|
||||
HTTP[S] by the API, RabbitMQ and the MySQL protocol by most components, DNS (resolution and XFR), ZooKeeper, Memcached.
|
||||
HTTP[S] by the API, RabbitMQ and the MySQL protocol by most components,
|
||||
DNS (resolution and XFR), ZooKeeper, Memcached.
|
||||
|
||||
What needs access to the Database?
|
||||
----------------------------------
|
||||
@ -91,7 +101,8 @@ API and Worker
|
||||
How do I monitor Designate?
|
||||
---------------------------
|
||||
|
||||
Designate can be monitored by various `monitoring systems listed here <https://wiki.openstack.org/wiki/Operations/Monitoring>`_
|
||||
Designate can be monitored by various
|
||||
`monitoring systems listed here <https://wiki.openstack.org/wiki/Operations/Monitoring>`_
|
||||
|
||||
OpenStack recommends `Monasca <https://wiki.openstack.org/wiki/Monasca>`_
|
||||
|
||||
@ -101,10 +112,13 @@ What are useful metrics to monitor?
|
||||
* General host monitoring, i.e. CPU load, memory usage, disk and network I/O
|
||||
* MySQL performance, errors and free disk space
|
||||
* Number of zones in ACTIVE, PENDING and ERROR status
|
||||
* API queries per second, broken down by "read" and "write" operation on zones, records, etc
|
||||
* Zone change propagation time i.e. how long does it takes for a record update to reach the resolvers
|
||||
* API queries per second, broken down by "read" and "write" operation on zones,
|
||||
records, etc
|
||||
* Zone change propagation time i.e. how long does it takes for a record update
|
||||
to reach the resolvers
|
||||
* Log messages containing having "ERROR" level
|
||||
* Quotas utilization i.e. number of existing records/zones against the maximum allowed
|
||||
* Quotas utilization i.e. number of existing records/zones against the
|
||||
maximum allowed
|
||||
* Memcached, RabbitMQ, ZooKeeper performance and errors
|
||||
|
||||
|
||||
|
||||
@ -12,4 +12,4 @@ Contents:
|
||||
kilo
|
||||
mitaka
|
||||
newton
|
||||
ocata
|
||||
ocata
|
||||
|
||||
@ -25,13 +25,13 @@ We have updated how the config data for pools is now stored.
|
||||
Previously there was a mix of content in the ``designate.conf`` file and in the
|
||||
designate database.
|
||||
|
||||
We have moved all of the data to the database in Mitaka, to avoid confusion, and
|
||||
avoid the massive complexity that exists in the config file.
|
||||
We have moved all of the data to the database in Mitaka, to avoid confusion,
|
||||
and avoid the massive complexity that exists in the config file.
|
||||
|
||||
.. warning:: This part of the upgrade **requires** downtime.
|
||||
|
||||
We have 2 new commands in the ``designate-manage`` utility that are able to assist
|
||||
the migration.
|
||||
We have 2 new commands in the ``designate-manage`` utility that are
|
||||
able to assist the migration.
|
||||
|
||||
To make the config syntax simpler we have a new YAML based config file that is
|
||||
used to load information into the database.
|
||||
@ -51,12 +51,14 @@ export it to the new YAML format.
|
||||
|
||||
designate-manage pool generate_file --file output.yml
|
||||
|
||||
This will create a YAML file, with all the currently defined pools, and all of their config.
|
||||
This will create a YAML file, with all the currently defined pools, and all
|
||||
of their config.
|
||||
|
||||
We suggest this is then migrated into a config management system, or other document management system.
|
||||
We suggest this is then migrated into a config management system,
|
||||
or other document management system.
|
||||
|
||||
From this point on all updates to pools should be done by updating this file, and
|
||||
running:
|
||||
From this point on all updates to pools should be done by updating this file,
|
||||
and running:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -27,9 +27,9 @@ configurations, as there is no breaking change from Mitaka.
|
||||
Breaking Changes
|
||||
----------------
|
||||
|
||||
The default port the ``designate-agent`` service listens on has changed from 53 to 5358.
|
||||
This matches the port we have always used in the sample configuration, and the port used
|
||||
in the agent backend class.
|
||||
The default port the ``designate-agent`` service listens on has changed
|
||||
from 53 to 5358. This matches the port we have always used in the sample
|
||||
configuration, and the port used in the agent backend class.
|
||||
|
||||
Upgrading Code and Enabling Services
|
||||
------------------------------------
|
||||
@ -73,8 +73,10 @@ be followed. This assumes you have all Mitaka Designate services running.
|
||||
[producer_task:worker_periodic_recovery]
|
||||
#interval = 120
|
||||
|
||||
3. Stop the ``designate-pool-manager`` and ``designate-zone-manager`` processes.
|
||||
4. Restart the ``designate-api``, ``designate-central`` and ``designate-mdns`` services.
|
||||
3. Stop the ``designate-pool-manager`` and
|
||||
``designate-zone-manager`` processes.
|
||||
4. Restart the ``designate-api``, ``designate-central`` and
|
||||
``designate-mdns`` services.
|
||||
5. Start the ``designate-producer`` and ``designate-worker`` services.
|
||||
|
||||
|
||||
@ -85,8 +87,8 @@ New Features
|
||||
multiple host:port pairs via the new "listen" configuration arguments for
|
||||
each service.
|
||||
- New pool scheduler "attribute" filter for scheduling zones across pools.
|
||||
This can be enabled in the ``[service:central]`` section of the config by adding
|
||||
``attribute`` to the list of values in the ``filters`` option.
|
||||
This can be enabled in the ``[service:central]`` section of the config by
|
||||
adding ``attribute`` to the list of values in the ``filters`` option.
|
||||
- An experimental agent backend to support TinyDNS, the DNS resolver from the
|
||||
djbdns tools.
|
||||
- An experimental agent backend to support Knot DNS 2
|
||||
@ -102,8 +104,8 @@ Deprecation Notices
|
||||
|
||||
- ``designate-api``'s api_host and api_port configuration options have been
|
||||
deprecated, please use the new combined "listen" argument in place of these.
|
||||
- ``designate-mdns``'s host and port configuration options have been deprecated,
|
||||
please use the new combined "listen" argument in place of these.
|
||||
- ``designate-mdns``'s host and port configuration options have been
|
||||
deprecated, please use the new combined "listen" argument in place of these.
|
||||
- ``designate-agents``'s host and port configuration options have been
|
||||
deprecated, please use the new combined "listen" argument in place of these.
|
||||
- ``designate-zone-manager`` and ``designate-pool-manager`` are now deprecated
|
||||
|
||||
@ -19,7 +19,11 @@
|
||||
Architecture
|
||||
============
|
||||
|
||||
Designate provides multi-tenant DNS as a Service. Designate provides a REST API, applies business logic, persists DNS data to a database, and orchestrates the propagation of the DNS data to configured pools of DNS servers. For a more detailed breakdown of responsibilities and components, see the components below.
|
||||
Designate provides multi-tenant DNS as a Service. Designate provides
|
||||
a REST API, applies business logic, persists DNS data to a database,
|
||||
and orchestrates the propagation of the DNS data to configured pools
|
||||
of DNS servers. For a more detailed breakdown of responsibilities
|
||||
and components, see the components below.
|
||||
|
||||
.. index::
|
||||
double: architecture; brief
|
||||
@ -33,60 +37,108 @@ High Level Topology
|
||||
|
||||
Designate API
|
||||
-----------------------
|
||||
designate-api provides the standard OpenStack style REST API service, accepting HTTP requests, validating authentication tokens with Keystone and passing them to the :ref:`designate-central` service over AMQP. Multiple versions of the API can be hosted, as well as API extensions, allowing for pluggable extensions to the core API.
|
||||
designate-api provides the standard OpenStack style REST API service,
|
||||
accepting HTTP requests, validating authentication tokens with Keystone and
|
||||
passing them to the :ref:`designate-central` service over AMQP.
|
||||
Multiple versions of the API can be hosted, as well as API extensions,
|
||||
allowing for pluggable extensions to the core API.
|
||||
|
||||
Although designate-api is capable of handling HTTPS traffic, it's typical to terminate HTTPS elsewhere, for example by placing nginx in front of designate-api or by letting the external facing load balancers terminate HTTPS.
|
||||
Although designate-api is capable of handling HTTPS traffic,
|
||||
it's typical to terminate HTTPS elsewhere, for example by placing nginx
|
||||
in front of designate-api or by letting the external facing load balancers
|
||||
terminate HTTPS.
|
||||
|
||||
.. _designate-central:
|
||||
|
||||
Designate Central
|
||||
-----------------------
|
||||
designate-central is the service that handles RPC requests via the MQ, it coordinates the persistent storage of data and applies business logic to data from the API. Storage is provided via plugins, typically SQLAlchemy, although MongoDB or other storage drivers should be possible.
|
||||
designate-central is the service that handles RPC requests via the MQ,
|
||||
it coordinates the persistent storage of data and applies business logic
|
||||
to data from the API. Storage is provided via plugins, typically SQLAlchemy,
|
||||
although MongoDB or other storage drivers should be possible.
|
||||
|
||||
.. _designate-mdns:
|
||||
|
||||
Designate MiniDNS
|
||||
-----------------------
|
||||
designate-mdns is the service that sends DNS NOTIFY and answers zone transfer (AXFR) requests. This allows Designate to integrate with any DNS server that supports these very standard methods of communicating. designate-mdns also encapsulates all other forms of DNS protocol that Designate performs. For example, sending SOA queries to check that a change is live.
|
||||
designate-mdns is the service that sends DNS NOTIFY and answers
|
||||
zone transfer (AXFR) requests. This allows Designate to integrate with
|
||||
any DNS server that supports these very standard methods of communicating.
|
||||
designate-mdns also encapsulates all other forms of DNS protocol
|
||||
that Designate performs. For example, sending SOA queries to check
|
||||
that a change is live.
|
||||
|
||||
.. _designate-worker:
|
||||
|
||||
Designate Worker
|
||||
----------------
|
||||
designate-worker is a service that manages state of the DNS servers Designate manages, and any other long-running or otherwise complicated piece of work. The worker reads configuration for DNS servers from the Designate database, which is populated via the pools.yaml file. These DNS server backends are loaded into the worker so it understands how to create, update, and delete zones and recordsets on each DNS server. The Worker is fully aware of DNS Server 'Pools', so a single worker process can manage many pools of DNS servers.
|
||||
designate-worker is a service that manages state of the DNS servers
|
||||
Designate manages, and any other long-running or otherwise complicated piece
|
||||
of work. The worker reads configuration for DNS servers from
|
||||
the Designate database, which is populated via the pools.yaml file.
|
||||
These DNS server backends are loaded into the worker so it understands
|
||||
how to create, update, and delete zones and recordsets on each DNS server.
|
||||
The Worker is fully aware of DNS Server 'Pools',
|
||||
so a single worker process can manage many pools of DNS servers.
|
||||
|
||||
.. _designate-producer:
|
||||
|
||||
Designate Producer
|
||||
------------------
|
||||
designate-producer is a service that handles the invocation of long-running and potentially large jobs. Producer processes start work for an automatically assigned shard of the zones Designate manages. Shards are allocated based on the first three characters of the zone ID (a UUID field). The number of shards under management of a single producer process is equal to the total number of shards divided by the number of producer processes. This means the more producer processes are started, the less work is created at any one time.
|
||||
designate-producer is a service that handles the invocation of long-running
|
||||
and potentially large jobs. Producer processes start work for an automatically
|
||||
assigned shard of the zones Designate manages. Shards are allocated based on
|
||||
the first three characters of the zone ID (a UUID field).
|
||||
The number of shards under management of a single producer process is equal
|
||||
to the total number of shards divided by the number of producer processes.
|
||||
This means the more producer processes are started, the less work is created
|
||||
at any one time.
|
||||
|
||||
The current implemented tasks in producer include emitting dns.zone.exists events for Ceilometer, purging deleted zones from database, polling secondary zones at their refresh intervals, generating delayed NOTIFY transactions, and invoking a periodic recovery of zones in an error state.
|
||||
The current implemented tasks in producer include emitting dns.zone.exists
|
||||
events for Ceilometer, purging deleted zones from database,
|
||||
polling secondary zones at their refresh intervals, generating delayed
|
||||
NOTIFY transactions, and invoking a periodic recovery of
|
||||
zones in an error state.
|
||||
|
||||
.. _designate-sink:
|
||||
|
||||
Designate Sink
|
||||
-----------------------
|
||||
designate-sink is an optional service which listens for event :ref:`notifications`, such as compute.instance.create.end, handlers are available for Nova and Neutron. Notification events can then be used to trigger record creation & deletion.
|
||||
designate-sink is an optional service which listens for event
|
||||
:ref:`notifications`, such as compute.instance.create.end,
|
||||
handlers are available for Nova and Neutron.
|
||||
Notification events can then be used to trigger record creation & deletion.
|
||||
|
||||
The current sink implementations generate simple forward lookup A records, using a format specified in handler-nova configuration. Any field in the event notification can be used to generate a record.
|
||||
The current sink implementations generate simple forward lookup A records,
|
||||
using a format specified in handler-nova configuration.
|
||||
Any field in the event notification can be used to generate a record.
|
||||
|
||||
.. _dns-backend:
|
||||
|
||||
DNS Backend
|
||||
-----------------------
|
||||
Backends are drivers for a particular DNS server.
|
||||
Designate supports multiple backend implementations, PowerDNS, BIND, NSD, DynECT, you are also free to implement your own backend to fit your needs, as well as extensions to provide extra functionality to complement existing backends.
|
||||
Designate supports multiple backend implementations, PowerDNS, BIND, NSD,
|
||||
DynECT, you are also free to implement your own backend to fit your needs,
|
||||
as well as extensions to provide extra functionality to complement
|
||||
existing backends.
|
||||
|
||||
.. _message-queue:
|
||||
|
||||
Message Queue
|
||||
-----------------------
|
||||
Designate uses oslo.rpc for messaging between components, therefore it inherits a requirement for a supported messaging bus (such as RabbitMQ, Qpid or ZeroMQ). Typically this means a RabbitMQ setup is dedicated to Designate, but as only a single virtualhost is required for a normal installation, you’re free to use other RabbitMQ instances as you see fit.
|
||||
Designate uses oslo.rpc for messaging between components, therefore it
|
||||
inherits a requirement for a supported messaging bus
|
||||
(such as RabbitMQ, Qpid or ZeroMQ). Typically this means a RabbitMQ
|
||||
setup is dedicated to Designate, but as only a single virtualhost
|
||||
is required for a normal installation, you’re free to use other
|
||||
RabbitMQ instances as you see fit.
|
||||
|
||||
.. _database:
|
||||
|
||||
Database/Storage
|
||||
-----------------------
|
||||
Storage drivers are drivers for a particular SQL/NoSQL server. Designate needs a SQLAlchemy-supported storage engine for the persistent storage of data. The recommended driver is MySQL.
|
||||
Storage drivers are drivers for a particular SQL/NoSQL server.
|
||||
Designate needs a SQLAlchemy-supported storage engine for the persistent
|
||||
storage of data. The recommended driver is MySQL.
|
||||
|
||||
|
||||
@ -24,16 +24,17 @@ The traffic between rndc and Bind is authenticated with a key.
|
||||
Designate Configuration
|
||||
-----------------------
|
||||
|
||||
Example configuration required for Bind9 operation. One section for each pool target
|
||||
Example configuration required for Bind9 operation.
|
||||
One section for each pool target
|
||||
|
||||
.. literalinclude:: sample_yaml_snippets/bind.yaml
|
||||
:language: yaml
|
||||
|
||||
The key and config files are relative to the host running Pool Manager (and can
|
||||
be different from the hosts running Bind)
|
||||
The key and config files are relative to the host running Pool Manager
|
||||
(and can be different from the hosts running Bind)
|
||||
|
||||
Then update the pools in designate - see :ref:`designate_manage_pool` for further details on
|
||||
the ``designate-manage pool`` command
|
||||
Then update the pools in designate - see :ref:`designate_manage_pool`
|
||||
for further details on the ``designate-manage pool`` command
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@ -45,7 +46,8 @@ Bind9 Configuration
|
||||
Ensure Bind can access the /etc/bind/rndc.conf and /etc/bind/rndc.key files and
|
||||
receive rndc traffic from Pool Manager.
|
||||
|
||||
Enable rndc addzone/delzone functionality by editing named.conf.options or named.conf and add this line under options
|
||||
Enable rndc addzone/delzone functionality by editing named.conf.options
|
||||
or named.conf and add this line under options
|
||||
|
||||
.. code-block:: c
|
||||
|
||||
|
||||
@ -25,8 +25,9 @@ Djbdns User documentation
|
||||
This page documents the Agent backend for `djbdns <https://cr.yp.to/djbdns.html>`_.
|
||||
|
||||
The agent runs on the same host as the `tinydns <https://cr.yp.to/djbdns/tinydns.html>`_ resolver.
|
||||
It receives DNS messages from Mini DNS using private DNS OPCODEs and classes and creates or deletes
|
||||
zones in the data.cdb file using `axfr-get <https://cr.yp.to/djbdns/axfr-get.html>`_ and
|
||||
It receives DNS messages from Mini DNS using private DNS OPCODEs
|
||||
and classes and creates or deletes zones in the data.cdb file using
|
||||
`axfr-get <https://cr.yp.to/djbdns/axfr-get.html>`_ and
|
||||
`tinydns-data <https://cr.yp.to/djbdns/tinydns-data.html>`_
|
||||
|
||||
Setting up Djbdns on Ubuntu Trusty
|
||||
@ -79,7 +80,8 @@ If needed, create the rootwrap filters, as root:
|
||||
sudo /usr/local/bin/designate-rootwrap /etc/designate/rootwrap.conf tcpclient -h
|
||||
sudo /usr/local/bin/designate-rootwrap /etc/designate/rootwrap.conf axfr-get -h
|
||||
|
||||
Configure the "service.agent" and "backend.agent.djbdns" sections in /etc/designate/designate.conf
|
||||
Configure the "service.agent" and "backend.agent.djbdns"
|
||||
sections in /etc/designate/designate.conf
|
||||
|
||||
Look in designate.conf.example for examples.
|
||||
|
||||
|
||||
@ -24,7 +24,10 @@ User documentation
|
||||
|
||||
This page documents the Agent backend for `gdnsd <http://gdnsd.org/>`_.
|
||||
|
||||
The agent runs on the same host as the resolver. It receives DNS messages from Mini DNS using private DNS OPCODEs and classes and creates/updates/deletes zones on gdnsd using zone files under the gdnsd configuration directory.
|
||||
The agent runs on the same host as the resolver. It receives DNS messages
|
||||
from Mini DNS using private DNS OPCODEs and classes and
|
||||
creates/updates/deletes zones on gdnsd using zone files under
|
||||
the gdnsd configuration directory.
|
||||
|
||||
The backend supports gdnsd from version 2.0
|
||||
|
||||
@ -63,7 +66,8 @@ Assuming gdnsd has been freshly installed on the system, run as root:
|
||||
# Test the daemon: it should respond with "gdnsd"
|
||||
dig @127.0.0.1 CH TXT +short
|
||||
|
||||
Configure the "service.agent" and "backend.agent.gdnsd" sections in /etc/designate/designate.conf
|
||||
Configure the "service.agent" and "backend.agent.gdnsd" sections
|
||||
in /etc/designate/designate.conf
|
||||
|
||||
Look in designate.conf.example for more complete examples
|
||||
|
||||
@ -79,7 +83,8 @@ Look in designate.conf.example for more complete examples
|
||||
#confdir_path = /etc/gdnsd
|
||||
#query_destination = 127.0.0.1
|
||||
|
||||
Ensure that the "zones" directory under "confdir_path" (default /etc/gdnsd) is readable and writable by the system user running the Designate Agent
|
||||
Ensure that the "zones" directory under "confdir_path" (default /etc/gdnsd)
|
||||
is readable and writable by the system user running the Designate Agent
|
||||
|
||||
Create an agent pool:
|
||||
|
||||
|
||||
@ -78,8 +78,9 @@ DNS view will be chosen as follows:
|
||||
* If found, then DNS view used will be <dns_view>.<network_view>, where
|
||||
<dns_view> is the value specified in designate.conf, and <network_view> is
|
||||
the name of the view found in the search.
|
||||
* If no such network view is found, then a network view will be created with the
|
||||
name <network_view>.<tenant_id>, where <network_view> is the value specified
|
||||
in designate.conf. This network view will be tagged with the TenantID EA.
|
||||
* If no such network view is found, then a network view will be created with
|
||||
the name <network_view>.<tenant_id>, where <network_view> is the value
|
||||
specified in designate.conf.
|
||||
This network view will be tagged with the TenantID EA.
|
||||
* If the DNS view does not exist (in either case above), then it will be
|
||||
created.
|
||||
|
||||
@ -24,8 +24,10 @@ Knot DNS 2 User documentation
|
||||
|
||||
This page documents the Agent backend for `Knot DNS <https://www.knot-dns.cz/>`_.
|
||||
|
||||
The agent runs on the same host as the resolver. It receives DNS messages from Mini DNS using private DNS OPCODEs and classes and creates or deletes zones on Knot using the knotc tool.
|
||||
It also instructs Knot to request AXFR from MiniDNS when a zone is created or updated.
|
||||
The agent runs on the same host as the resolver. It receives DNS messages from
|
||||
Mini DNS using private DNS OPCODEs and classes and creates or deletes zones
|
||||
on Knot using the knotc tool. It also instructs Knot to request AXFR
|
||||
from MiniDNS when a zone is created or updated.
|
||||
|
||||
Support matrix:
|
||||
|
||||
@ -133,7 +135,8 @@ If needed, create a rootwrap filter, as root:
|
||||
# Check the filter:
|
||||
sudo /usr/local/bin/designate-rootwrap /etc/designate/rootwrap.conf knotc status
|
||||
|
||||
Configure the "service.agent" and "backend.agent.knot2" sections in /etc/designate/designate.conf
|
||||
Configure the "service.agent" and "backend.agent.knot2" sections
|
||||
in /etc/designate/designate.conf
|
||||
|
||||
Look in designate.conf.example for examples
|
||||
|
||||
|
||||
@ -58,12 +58,14 @@ and do a pip install. Example:
|
||||
git clone https://github.com/openstack/designate
|
||||
pip install .\\designate
|
||||
|
||||
After that, we need to configure the Designate Agent. Inside the github repository,
|
||||
there is a folder named "etc/designate" which can be used as default configuration.
|
||||
After that, we need to configure the Designate Agent.
|
||||
Inside the github repository, there is a folder named "etc/designate"
|
||||
which can be used as default configuration.
|
||||
|
||||
Copy the folder somewhere else, for this example we will copy it to C:\\etc\\designate
|
||||
Inside the configuration folder, make a copy of designate.conf.sample and rename
|
||||
the copy to designate.conf
|
||||
Copy the folder somewhere else, for this example we will copy it to
|
||||
C:\\etc\\designate
|
||||
Inside the configuration folder, make a copy of designate.conf.sample
|
||||
and rename the copy to designate.conf
|
||||
Example:
|
||||
|
||||
.. code-block:: console
|
||||
@ -89,7 +91,8 @@ Ensure that "policy_file" under the [default] section is set:
|
||||
|
||||
policy_file = C:\\etc\\designate\\policy.json
|
||||
|
||||
Start the designate agent using (Python 2.7 was installed in the default location C:\\Python27):
|
||||
Start the designate agent using
|
||||
(Python 2.7 was installed in the default location C:\\Python27):
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -51,7 +51,8 @@ See `PowerDNS Docs`_ for details.
|
||||
|
||||
$ designate-manage pool update
|
||||
|
||||
See :ref:`designate_manage_pool` for further details on the ``designate-manage pool``
|
||||
command, and :ref:`pools` for information about the yaml file syntax
|
||||
See :ref:`designate_manage_pool` for further details on
|
||||
the ``designate-manage pool`` command, and :ref:`pools`
|
||||
for information about the yaml file syntax
|
||||
|
||||
.. _PowerDNS Docs: https://doc.powerdns.com/md/authoritative/installation/
|
||||
|
||||
@ -60,8 +60,9 @@ You need to configure PowerDNS to use the MySQL backend.
|
||||
|
||||
$ designate-manage pool update
|
||||
|
||||
See :ref:`designate_manage_pool` for further details on the ``designate-manage pool``
|
||||
command, and :ref:`pools` for information about the yaml file syntax
|
||||
See :ref:`designate_manage_pool` for further details on
|
||||
the ``designate-manage pool`` command, and :ref:`pools`
|
||||
for information about the yaml file syntax
|
||||
|
||||
4. Setup the database schema.
|
||||
|
||||
@ -69,7 +70,9 @@ command, and :ref:`pools` for information about the yaml file syntax
|
||||
|
||||
$ designate-manage powerdns sync <pool_id>
|
||||
|
||||
See :ref:`designate_manage_powerdns` for further details on the ``designate-manage powerdns`` command
|
||||
See :ref:`designate_manage_powerdns` for further details on
|
||||
the ``designate-manage powerdns`` command
|
||||
|
||||
5. Restart PowerDNS and it should be ready to serve queries using the MySQL database as the backing store.
|
||||
5. Restart PowerDNS and it should be ready to serve queries
|
||||
using the MySQL database as the backing store.
|
||||
|
||||
|
||||
@ -9,22 +9,27 @@ Getting Involved
|
||||
|
||||
#openstack-dns
|
||||
--------------
|
||||
There is an active IRC channel at irc://freenode.net/#openstack-dns, where many of the designate contributors can be found, as
|
||||
There is an active IRC channel at irc://freenode.net/#openstack-dns,
|
||||
where many of the designate contributors can be found, as
|
||||
well as users from various organisations.
|
||||
|
||||
Weekly meetings
|
||||
---------------
|
||||
There is a weekly irc meet. The agenda and other details are listed at
|
||||
`Designate meetings wiki page`_. Currently the meeting is
|
||||
held every Wednesday at 17:00 UTC on the IRC channel irc://freenode.net/#openstack-meeting-alt
|
||||
held every Wednesday at 17:00 UTC on the IRC channel
|
||||
irc://freenode.net/#openstack-meeting-alt
|
||||
|
||||
Contributing
|
||||
------------
|
||||
We welcome fixes, extensions, documentation, pretty much anything that helps improve Designate, contributing is easy & follows
|
||||
the standard OpenStack `Gerrit workflow`_, if you're looking for something to do, you could always checkout the blueprint_ & bug_
|
||||
We welcome fixes, extensions, documentation, pretty much anything that
|
||||
helps improve Designate, contributing is easy & follows
|
||||
the standard OpenStack `Gerrit workflow`_, if you're looking for
|
||||
something to do, you could always checkout the blueprint_ & bug_
|
||||
lists.
|
||||
|
||||
Assuming you've already got a working :ref:`Development Environment`, here's a quick summary:
|
||||
Assuming you've already got a working :ref:`Development Environment`,
|
||||
here's a quick summary:
|
||||
|
||||
Install the git-review package to make life easier
|
||||
|
||||
@ -70,10 +75,11 @@ follow this guidance, for example, there is currently no reserved IDN domain
|
||||
name.
|
||||
|
||||
We prefer to use these names and IP blocks to avoid causing any unexpected
|
||||
collateral damage to the rightful owners of the non-reserved names and IP space.
|
||||
For example, publishing an email address in our codebase will more than likely
|
||||
be picked up by spammers, while published URLs etc using non-reserved names or
|
||||
IP space will likely trigger search indexers etc to begin crawling.
|
||||
collateral damage to the rightful owners of the non-reserved names and
|
||||
IP space. For example, publishing an email address in our codebase will
|
||||
more than likely be picked up by spammers, while published URLs etc using
|
||||
non-reserved names or IP space will likely trigger search indexers etc
|
||||
to begin crawling.
|
||||
|
||||
Reserved Domains
|
||||
~~~~~~~~~~~~~~~~
|
||||
@ -156,7 +162,8 @@ Example:
|
||||
|
||||
`User documentation <backend.html>`_
|
||||
|
||||
When updating a module, please ensure that the related user documentation is updated as well.
|
||||
When updating a module, please ensure that the related user documentation is
|
||||
updated as well.
|
||||
|
||||
Docstrings
|
||||
~~~~~~~~~~
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
Source Code Documentation
|
||||
Source Code Documentation
|
||||
-------------------------
|
||||
|
||||
.. toctree::
|
||||
@ -12,4 +12,3 @@ Source Code Documentation
|
||||
quota
|
||||
sink
|
||||
storage
|
||||
|
||||
|
||||
@ -2,9 +2,11 @@
|
||||
DNS Server Driver Support Matrix
|
||||
================================
|
||||
|
||||
This info should be maintained along with the list of current driver maintainers responsible for the “Non Integrated” backends.
|
||||
This info should be maintained along with the list of current driver
|
||||
maintainers responsible for the “Non Integrated” backends.
|
||||
The upkeep of this list will fall on the PTL or his/her delegate.
|
||||
|
||||
Should a backend’s grade be in dispute, it falls on the current project PTL to make the final decision after listening to all sides concerns.
|
||||
Should a backend’s grade be in dispute, it falls on the current project PTL
|
||||
to make the final decision after listening to all sides concerns.
|
||||
|
||||
.. support_matrix::
|
||||
|
||||
@ -17,19 +17,21 @@
|
||||
Development Environment on Ubuntu
|
||||
*********************************
|
||||
|
||||
Designate is comprised of four main components :ref:`designate-api`, :ref:`designate-central`,
|
||||
designate-mdns, and designate-pool-manager, supported by a few
|
||||
standard open source components. For more information see :ref:`architecture`.
|
||||
Designate is comprised of four main components :ref:`designate-api`,
|
||||
:ref:`designate-central`, designate-mdns, and designate-pool-manager,
|
||||
supported by a few standard open source components.
|
||||
For more information see :ref:`architecture`.
|
||||
|
||||
There are many different options for customizing Designate, and two of these options
|
||||
have a major impact on the installation process:
|
||||
There are many different options for customizing Designate, and two of
|
||||
these options have a major impact on the installation process:
|
||||
|
||||
* The storage backend used (SQLite or MySQL)
|
||||
* The DNS backend used (PowerDNS or BIND9)
|
||||
|
||||
This guide will walk you through setting up a typical development environment for Designate,
|
||||
using BIND9 as the DNS backend and MySQL as the storage backend. For a more complete discussion on
|
||||
installation & configuration options, please see :ref:`architecture`.
|
||||
This guide will walk you through setting up a typical development environment
|
||||
for Designate, using BIND9 as the DNS backend and MySQL as the storage
|
||||
backend. For a more complete discussion on installation & configuration
|
||||
options, please see :ref:`architecture`.
|
||||
|
||||
For this guide you will need access to an Ubuntu Server (16.04).
|
||||
|
||||
@ -92,7 +94,8 @@ Installing Designate
|
||||
6. Change directories to the etc/designate folder.
|
||||
|
||||
.. note::
|
||||
Everything from here on out should take place in or below your etc/designate folder
|
||||
Everything from here on out should take place in or below your
|
||||
etc/designate folder
|
||||
|
||||
::
|
||||
|
||||
@ -154,12 +157,15 @@ Install the MySQL server package
|
||||
$ sudo apt install mysql-server
|
||||
|
||||
|
||||
If you do not have MySQL previously installed, you will be prompted to change the root password.
|
||||
By default, the MySQL root password for Designate is "password". You can:
|
||||
If you do not have MySQL previously installed, you will be prompted to change
|
||||
the root password. By default, the MySQL root password for Designate
|
||||
is "password". You can:
|
||||
|
||||
* Change the root password to "password"
|
||||
* If you want your own password, edit the designate.conf file and change any instance of
|
||||
"mysql+pymysql://root:password@127.0.0.1/designate?charset=utf8" to "mysql+pymysql://root:YOUR_PASSWORD@127.0.0.1/designate?charset=utf8"
|
||||
* If you want your own password, edit the designate.conf file and change
|
||||
any instance of
|
||||
"mysql+pymysql://root:password@127.0.0.1/designate?charset=utf8"
|
||||
to "mysql+pymysql://root:YOUR_PASSWORD@127.0.0.1/designate?charset=utf8"
|
||||
|
||||
You can change your MySQL password anytime with the following command::
|
||||
|
||||
@ -293,7 +299,8 @@ Start the other Services
|
||||
.. index::
|
||||
double: install; services
|
||||
|
||||
Open up some new ssh windows and log in to your server (or open some new screen/tmux sessions).
|
||||
Open up some new ssh windows and log in to your server
|
||||
(or open some new screen/tmux sessions).
|
||||
|
||||
::
|
||||
|
||||
@ -314,7 +321,8 @@ You’ll now be seeing the logs from the other services.
|
||||
Exercising the API
|
||||
==================
|
||||
|
||||
.. note:: If you have a firewall enabled, make sure to open port 53, as well as Designate's default port (9001).
|
||||
.. note:: If you have a firewall enabled, make sure to open port 53,
|
||||
as well as Designate's default port (9001).
|
||||
|
||||
Using a web browser, curl statement, or a REST client, calls can be made to the
|
||||
Designate API. You can find the various API calls on the api-ref_ document.
|
||||
@ -333,8 +341,8 @@ For example:
|
||||
$ curl 127.0.0.1:9001/v2/zones
|
||||
{"zones": [{"status": "ACTIVE",.....
|
||||
|
||||
The ``ACTIVE`` status shows that the zone propagated. So you should be able to perform a DNS query and
|
||||
see it:
|
||||
The ``ACTIVE`` status shows that the zone propagated. So you should be able to
|
||||
perform a DNS query and see it:
|
||||
|
||||
::
|
||||
|
||||
@ -347,8 +355,10 @@ You can find the IP Address of your server by running
|
||||
|
||||
ip addr show eth0 | grep "inet\b" | awk '{print $2}' | cut -d/ -f1
|
||||
|
||||
If you have Keystone set up, you can use it by configuring the ``[keystone_authtoken]`` section and changing
|
||||
the ``auth_strategy = keystone`` in the ``service:api`` section. This will make it easier to use clients
|
||||
like the ``openstack`` CLI that expect Keystone.
|
||||
If you have Keystone set up, you can use it by configuring
|
||||
the ``[keystone_authtoken]`` section and changing
|
||||
the ``auth_strategy = keystone`` in the ``service:api`` section.
|
||||
This will make it easier to use clients like the ``openstack``
|
||||
CLI that expect Keystone.
|
||||
|
||||
.. _api-ref: https://developer.openstack.org/api-ref/dns/
|
||||
|
||||
@ -137,8 +137,8 @@ Install and configure components
|
||||
|
||||
# su -s /bin/sh -c "designate-manage database sync" designate
|
||||
|
||||
#. Start the designate central and API services and configure them to start when
|
||||
the system boots:
|
||||
#. Start the designate central and API services and configure them
|
||||
to start when the system boots:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -137,8 +137,8 @@ Install and configure components
|
||||
|
||||
# su -s /bin/sh -c "designate-manage database sync" designate
|
||||
|
||||
#. Start the designate central and API services and configure them to start when
|
||||
the system boots:
|
||||
#. Start the designate central and API services and configure them
|
||||
to start when the system boots:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
@ -12,4 +12,4 @@ Contents:
|
||||
|
||||
rest
|
||||
manage-ptr-records
|
||||
secondary-zones
|
||||
secondary-zones
|
||||
|
||||
@ -52,11 +52,14 @@ HTTP Headers
|
||||
These headers work for all APIs
|
||||
|
||||
* X-Designate-Edit-Managed-Records
|
||||
- Allows admins (or users with the right role) to modify managed records (records created by designate-sink / reverse floating ip API)
|
||||
- Allows admins (or users with the right role) to modify managed records
|
||||
(records created by designate-sink / reverse floating ip API)
|
||||
* X-Auth-All-Projects
|
||||
- Allows admins (or users with the right role) to view and edit zones / recordsets for all tenants
|
||||
- Allows admins (or users with the right role) to view and edit
|
||||
zones / recordsets for all tenants
|
||||
* X-Auth-Sudo-Tenant-ID / X-Auth-Sudo-Project-ID
|
||||
- Allows admins (or users with the right role) to impersonate another tenant specified by this header
|
||||
- Allows admins (or users with the right role) to impersonate another
|
||||
tenant specified by this header
|
||||
|
||||
API Versions
|
||||
============
|
||||
|
||||
@ -11,10 +11,10 @@
|
||||
http://www.apache.org/licenses/LICENSE-2.0
|
||||
|
||||
Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
License for the specific language governing permissions and limitations
|
||||
under the License.
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions
|
||||
and limitations under the License.
|
||||
|
||||
Quotas
|
||||
======
|
||||
@ -30,8 +30,8 @@ added to the designate.conf file under ``[service:api]`` section ::
|
||||
enable_api_admin = True
|
||||
enabled_extensions_admin = quotas
|
||||
|
||||
Once these lines have been added, restart the designate-central and designate-api
|
||||
services.
|
||||
Once these lines have been added, restart the designate-central
|
||||
and designate-api services.
|
||||
|
||||
Get Quotas
|
||||
----------
|
||||
|
||||
@ -63,4 +63,4 @@ Ping a host on a RPC topic
|
||||
}
|
||||
|
||||
:statuscode 200: Success
|
||||
:statuscode 401: Access Denied
|
||||
:statuscode 401: Access Denied
|
||||
|
||||
@ -235,4 +235,4 @@ Report record counts
|
||||
|
||||
:form records: Records count
|
||||
:statuscode 200: Success
|
||||
:statuscode 401: Access Denied
|
||||
:statuscode 401: Access Denied
|
||||
|
||||
@ -109,4 +109,4 @@ Synchronize one record
|
||||
Content-Type: application/json
|
||||
|
||||
:statuscode 200: Success
|
||||
:statuscode 401: Access Denied
|
||||
:statuscode 401: Access Denied
|
||||
|
||||
@ -61,7 +61,9 @@ Skip this section if you have a master already to use.
|
||||
Install
|
||||
^^^^^^^
|
||||
|
||||
For some reason there's a bug with the nsd package so it doesn't create the user that it needs for the installation. So we'll create that before installing the package.
|
||||
For some reason there's a bug with the nsd package so it doesn't create
|
||||
the user that it needs for the installation.
|
||||
So we'll create that before installing the package.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -80,7 +82,8 @@ Add the following to /etc/nsd/nsd.conf
|
||||
|
||||
.. note::
|
||||
|
||||
If you're wondering why we set notify to `192.168.27.100`:`5354` it's because MDNS runs on 5354 by default.
|
||||
If you're wondering why we set notify to `192.168.27.100`:`5354`
|
||||
it's because MDNS runs on 5354 by default.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@ -173,8 +176,8 @@ Creating the Zone
|
||||
When you create a domain in Designate there are two possible initial actions:
|
||||
|
||||
- Domain is created but transfer fails if it's not available yet in master,
|
||||
then typically the initial transfer will be done once the master sends first
|
||||
NOTIFY.
|
||||
then typically the initial transfer will be done once the master sends
|
||||
first NOTIFY.
|
||||
|
||||
- Domain is created and transfers straight away.
|
||||
|
||||
|
||||
@ -3,6 +3,7 @@ Rally job related files
|
||||
|
||||
This directory contains rally tasks and plugins that are run by OpenStack CI.
|
||||
|
||||
|
||||
Structure:
|
||||
|
||||
* designate-designate.yaml is rally task that will be run in gates
|
||||
|
||||
@ -1,8 +1,9 @@
|
||||
|
||||
Rally plugins
|
||||
=============
|
||||
|
||||
|
||||
All *.py modules from this directory will auto loaded by Rally and all
|
||||
All `*.py` modules from this directory will auto loaded by Rally and all
|
||||
plugins will be discoverable. There is no need in any extra configuration
|
||||
and there is no difference between writing them here and in rally code base.
|
||||
|
||||
|
||||
@ -3,4 +3,4 @@
|
||||
==============================
|
||||
|
||||
.. release-notes::
|
||||
:branch: origin/stable/liberty
|
||||
:branch: origin/stable/liberty
|
||||
|
||||
@ -2,4 +2,4 @@
|
||||
Current Series Release Notes
|
||||
==============================
|
||||
|
||||
.. release-notes::
|
||||
.. release-notes::
|
||||
|
||||
@ -22,3 +22,4 @@ bandit>=1.1.0 # Apache-2.0
|
||||
os-api-ref>=1.4.0 # Apache-2.0
|
||||
zake>=0.1.6 # Apache-2.0
|
||||
openstackdocstheme>=1.17.0 # Apache-2.0
|
||||
doc8>=0.6.0 # Apache-2.0
|
||||
|
||||
2
tox.ini
2
tox.ini
@ -68,6 +68,8 @@ deps = -r{toxinidir}/test-requirements.txt
|
||||
basepython = python2.7
|
||||
commands = sh tools/pretty_flake8.sh
|
||||
{[testenv:bandit]commands}
|
||||
doc8 README.rst releasenotes/source doc/source rally-jobs \
|
||||
devstack/README.rst contrib --ignore D000
|
||||
|
||||
[testenv:genconfig]
|
||||
commands = oslo-config-generator --config-file=etc/designate/designate-config-generator.conf
|
||||
|
||||
Loading…
Reference in New Issue
Block a user