<div dir="ltr"><div>The Designate sink service relies on sink file(s) that contain the domain</div><div>id(s) of the domains that automatically generated records should be added to.</div><div>At the moment the designate charm creates a server and domains during charm</div><div>installation if the neutron-domain and/or nova-domain config options have been</div><div>set. It then renders the sink files accordingly. This is done via the</div><div>designate cli and obviously relies on the keystone API and designate API</div><div>services being up and avaliable. This is unsuprisngly proving to be unreliable</div><div>and racey, particularly during HA deployments.</div><div><br></div><div>The heat charm has a similiar issue in that it relies on a domain to have been</div><div>created before heat can be used. But rather than try and create the domain</div><div>during charm installation the heat charm exposes an action which should be</div><div>run post-installation to create the domain.</div><div><br></div><div>I think that the designate charm should be updated to work in a similar way to</div><div>the heat charm and that the server and domain creation and sink file rendering</div><div>should be done via a post-deployment action rather than during deployment</div><div>time. There is a complication to this approach. All the designate API units</div><div>will need to render sink configurations containing the domain id(s) once the</div><div>creation action has run. I can think of two similar ways to achieve this:</div><div><br></div><div>1) Expose a server and domain creation action that must be run on the leader.</div><div>   During the action the leader then sets the domain ids via the leader db.</div><div>   The non-leaders can then respond to leader-settings-changed and render</div><div>   their sink file(s). Storing the sink config in the leader-db also has the</div><div>   advantage that if the designate service is scaled out at a later date then</div><div>   the new unit will still have access to the sink configuration and can</div><div>   render the sink files.</div><div><br></div><div>2) A very similar approach would be to push the creation of servers and</div><div>   domains back to the administrator to perform and expose a generic action</div><div>   for creating sink files which accepts the domain id as one of its</div><div>   arguments. Again this would need to be run on the leader and propogated via</div><div>   leader-settings </div><div><br></div><div>I'm inclined to do option 2 does anyone have any objections or suggestions for an</div><div>alternative approach ?</div><div><br></div><div>Thanks</div><div>Liam</div><div><br></div></div>