Open Stack

The Designate sink service relies on sink file(s) that contain the domain
id(s) of the domains that automatically generated records should be added
to.
At the moment the designate charm creates a server and domains during charm
installation if the neutron-domain and/or nova-domain config options have
been
set. It then renders the sink files accordingly. This is done via the
designate cli and obviously relies on the keystone API and designate API
services being up and avaliable. This is unsuprisngly proving to be
unreliable
and racey, particularly during HA deployments.

The heat charm has a similiar issue in that it relies on a domain to have
been
created before heat can be used. But rather than try and create the domain
during charm installation the heat charm exposes an action which should be
run post-installation to create the domain.

I think that the designate charm should be updated to work in a similar way
to
the heat charm and that the server and domain creation and sink file
rendering
should be done via a post-deployment action rather than during deployment
time. There is a complication to this approach. All the designate API units
will need to render sink configurations containing the domain id(s) once the
creation action has run. I can think of two similar ways to achieve this:

1) Expose a server and domain creation action that must be run on the
leader.
   During the action the leader then sets the domain ids via the leader db.
   The non-leaders can then respond to leader-settings-changed and render
   their sink file(s). Storing the sink config in the leader-db also has the
   advantage that if the designate service is scaled out at a later date
then
   the new unit will still have access to the sink configuration and can
   render the sink files.

2) A very similar approach would be to push the creation of servers and
   domains back to the administrator to perform and expose a generic action
   for creating sink files which accepts the domain id as one of its
   arguments. Again this would need to be run on the leader and propogated
via
   leader-settings

I'm inclined to do option 2 does anyone have any objections or suggestions
for an
alternative approach ?

Thanks
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171122/c2770284/attachment.html>