Difference between revisions of "Designate/Blueprints/Recordset Record API Redesign"
(Created page with "Contents 1 Overview 1.1 Summary 2 API Changes 2.1 One Per Change 2.1.1 Example of Call (HTTP Verb) 3 Database Changes Overview Gerrit...") |
|||
| Line 1: | Line 1: | ||
| − | + | == Overview == | |
| − | + | {| class="wikitable" | |
| − | + | |- | |
| − | + | ! Gerrit Patch || [] | |
| − | + | |- | |
| − | + | ! Launchpad Blueprint || [https://blueprints.launchpad.net/designate/+spec/blacklist] | |
| − | + | |} | |
| − | + | This blueprint proposes to provide an admin-only API call to dynamically manage blacklisted domains. | |
| − | |||
| − | |||
| − | |||
| − | + | Blacklisted domains are domains that Designate will prevent from being used at the TLD level. It does not prevent them from being used as lower level domains. For instance, if google.com is blacklisted, then that would effectively stop someone trying to add the domain www.google.com. However, it would not prohibit google.com.au, so that domain would need to be blacklisted separately, if desired. | |
| − | |||
| − | + | Currently, the list of blacklisted domains resides in the .config file. Designate must be restarted before any changes to the .config file take place. One possible solution to this could be to make the .config file reloadable without restarting the Designate service. However, there are only limited Operations personnel who have access to the .config file, and while blacklisted domains are not normally added or changed often, when it is needed, it needs to be done quickly. Providing an API call would allow support personnel to be given admin rights to this API call so that they can effectively make the change in a timely manner, without trying to find the one or two people who can change the .config file. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | To implement this management capability, a new API call will be created, along with a new database table to store the blacklisted domains, and they will no longer be in the .config file. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 18:29, 29 April 2014
Overview
| Gerrit Patch | [] |
|---|---|
| Launchpad Blueprint | [1] |
This blueprint proposes to provide an admin-only API call to dynamically manage blacklisted domains.
Blacklisted domains are domains that Designate will prevent from being used at the TLD level. It does not prevent them from being used as lower level domains. For instance, if google.com is blacklisted, then that would effectively stop someone trying to add the domain www.google.com. However, it would not prohibit google.com.au, so that domain would need to be blacklisted separately, if desired.
Currently, the list of blacklisted domains resides in the .config file. Designate must be restarted before any changes to the .config file take place. One possible solution to this could be to make the .config file reloadable without restarting the Designate service. However, there are only limited Operations personnel who have access to the .config file, and while blacklisted domains are not normally added or changed often, when it is needed, it needs to be done quickly. Providing an API call would allow support personnel to be given admin rights to this API call so that they can effectively make the change in a timely manner, without trying to find the one or two people who can change the .config file.
To implement this management capability, a new API call will be created, along with a new database table to store the blacklisted domains, and they will no longer be in the .config file.
