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
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
