Designate is a great service but unfortunatly, we don't have
full time maintainers therefore we can't certify the service will be
tested and work correctly.
In this patch, we create an experimental folder and put Designate in it.
Change-Id: I8a587ebdca2c7e64ab8348155cf75c2dbb65a5ed
This change combines the previous puppet and docker files into a single
file that performs the docker service installation and configuration
for the designate Producer, Worker, and Mdns services.
Change-Id: Ibbd14996eb6fc9b2e45dd9f24d3b7156c42da990
Related-Blueprint: services-yaml-flattening
This change combines the previous puppet and docker files into a single
file that performs the docker service installation and configuration
for the designate API, Central, and Sink services.
Related-Blueprint: services-yaml-flattening
Change-Id: I1c18780b252ce118836462b0857040fe1a3e8789
This change combines the previous puppet and docker files into a single
file that performs the docker service installation and configuration
for the neutron-api, neutron-dhcp, and neutron-l3 services.
With this patch the baremetal version of each respective neutron service
has been removed.
Related-Blueprint: services-yaml-flattening
Change-Id: I6d1fae29498d2c8bffff2ccffcfbf0b605350205
Because the designate parameters will always need to be edited for
a deployment, a copy of the environment must be made. However,
because there were resource_registry entries in the previous
enable-designate environments those relative paths would become
invalid if the file was moved. Splitting the resource_registry
entries from the user-configured parameters should eliminate this
problem.
Change-Id: I8817a36e20e7a75b340a0d6cb0abf09e57b1fd63
The pool configuration for an ha deployment of designate looks quite
a bit different from the nonha one, so it's useful to provide a
separate example environment for it.
Change-Id: I69b3c44b368bab3fff885e67fa6523fbb1c80347
It isn't useful for much of anything in a production deployment
and it conflicts with the local DNS server in CI.
Change-Id: Ied3ecdc71bfdf9bb6439e2c9464aa01346e69226
Closes-Bug: 1795043
This is necessary as the settings in this file are deployment
specific, so the defaults will never be correct. For simplicity,
the enablement environment includes the sample pools.yaml content
from the Designate docs. It can then be easily modified to match
the actual intended deployment environment.
Depends-On: https://review.openstack.org/580524
Change-Id: I84cc3b06ac77c723994be0f49960a93e0dbba0ad
For security, it is best to split authoritative and recursive
nameservers. This way a security vulnerability that only affects
one type of server won't provide an exploit for the other too.
For Designate, the managed BIND server is the authoritative one.
We can use Neutron's internal DNS server as the recursive server, or
users can point at their DNS server of choice. To make sure our
defaults work out of the box, this change enables the Neutron
internal DNS by default and users can change that if they choose.
Since that means we no longer need recursion in BIND, we should shut
it off, which this also does.
Change-Id: I4193436fdfd05bfd641fc32b58cc9bff24310a80
This service isn't ready for production in TripleO yet, so we
should make sure that's clear in the enablement environment.
Change-Id: I4a5a5f347dcb4f43f7f802648624165c80023e0d