designate/doc/source/integrations.rst
Endre Karlson 6fd81240b7 FloatingIP PTR record functionality
* Central methods update_floatingip, get_floatingip, list_floatingip
* API according to
* https://wiki.openstack.org/wiki/Designate/Blueprints/Reverse
* Put network functionanlity into a pluggable api class (In case we want
* more)

blueprint floating-ip-ptrs

Change-Id: Ic9194e5bcfc8d25126b9e84652144f58cddcccfe
2014-01-15 16:21:14 +01:00

53 lines
1.9 KiB
ReStructuredText

============
Integrations
============
This page overviews integrations with other services like Neutron and others to
make use of Designate more convenient.
Reverse - FloatingIP
====================
The FloatingIP PTR feature of Designate relies on information of the FloatingIP
which is in a different service then Designate itself. It can be in any service
as long as their is a "plugin" for it that can be loaded via the configuration
setting called "network_api".
* Controller, views and schemas in the V2 API
* RPC Client towards Central used by the API and Sink
* Logic in Central to make it convenient for setting, unsetting, listing and
getting FloatingIP PTR records compared to the Records themselves which would
be more work. (This is outlined in code docstrings for the specific methods.)
* Sink handlers for the varios backend to help us be more concistent.
Record invalidation
^^^^^^^^^^^^^^^^^^^
Happens mainly happens via comparing a Tenant's FloatngIPs
towards the list we have of Records which are of a certain plugin type and
with the use of a Sink handler that listens for incoming events from the
various services.
Configuring Neutron
-------------------
Configuring the FloatingIP feature is really simple:
[network_api:neutron]
# endpoints = RegionOne|http://localhost:9696
# endpoint_type = publicURL
# timeout = 30
# admin_username = designate
# admin_password = designate
# admin_tenant_name = designate
# auth_url = http://localhost:35357/v2.0
# insecure = False
# auth_strategy = keystone
# ca_certificates_file = /etc/path/to/ca.pem
Note that using admin_user, admin_password and admin_tenant_name is optional,
if not present we'll piggyback on the context.auth_token passed in by the API.
.. note..
If "endpoints" is not configured and there's no service catalog is present
in the context passed by the API to Central the request will fail in
a NoEndpoint exception.