On 16/06/13 05:06, Ryan Lane wrote: > > If you use OpenStack you have no choice but to use Keystone. This isn't > really the case with Designate, and I think it would be difficult for it > to be a required service. Maybe Keystone could have a driver that > interacts with Designate for global registry, if Designate is being used?
Yea, I see Designate as something which is entirely optional to an OpenStack cloud. And, as a general purpose DNS service, hosting of the service catalog would require no changes on Designate's side. > > It really makes sense for this to be a standalone service that other > services interact with. It's very possible that some infrastructures may > choose to use Designate to manage their DNS without using any other > OpenStack service. > I absolutely agree, Designate has no hard dependencies on OpenStack services and frankly - I see no reason to introduce one. Isolated services with a clear and simple goal are always better IMHO than interdependent services with everything, even the kitchen sink, included! I actually think this shows through in Designate's architecture. Designate is made up of 4 small and discrete services: designate-api - A thin API service that provides the HTTP endpoint. This deserializes and validates the structure of incoming API calls, and forwards them to central. designate-central - The core of the service. All DB interactions, authorization etc happen here. designate-agent - An optional service that coordinates remote DNS servers. Say you decide to use BIND9, you'll need a way to write out the zonefiles on each DNS service as changes are made. With PowerDNS, or any other DB backed DNS service, this service can be skipped. designate-sink - Another optional service that hooks into the nova/quantum notifications and performs actions based on plugins. For example, you could write a plugin to create DNS records for instances as they boot. If Designate is incubated, I can see this service being deprecated and the relevant hooks being placed straight into Nova/Quantum rather than relying on the notification feed. So - What I'm getting at is, it's possible to use Designate is many different ways. Maybe you don't want to host DNS for $customer, but do want to maintain forward/reverse DNS for instances.. You can do that by running just central and sink[1]. Or maybe you only want to host $customers DNS, you just need the central and api services. Some people see this as complexity, but I see it as series of well defined and composable components that can hopefully be used in ways we never planned for! Thanks, Kiall [1]: Okay.. So some initial config would require the API.. but it wouldn't need to be exposed to customers, or even kept running after the initial config. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
