[openstack-dev] [charms] [designate] Domain and server creation during deployment
liam.young at canonical.com
Wed Nov 22 14:58:34 UTC 2017
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
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
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
and racey, particularly during HA deployments.
The heat charm has a similiar issue in that it relies on a domain to have
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
the heat charm and that the server and domain creation and sink file
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
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
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
I'm inclined to do option 2 does anyone have any objections or suggestions
alternative approach ?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev