designate plugin is not indexing/listening for server(nameservers)

Bug #1563497 reported by Lakshmi N Sampath
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Searchlight

Bug Description

nameservers are not being indexed in designate plugin.


designate server-list
| id | name |
| b4502fe4-5a8e-410f-9faa-12774bcf655f | |
| 165cea96-b05e-4028-852d-8febe1aea6d9 | |

designate server-get b4502fe4-5a8e-410f-9faa-12774bcf655f
| Field | Value |
| id | 2016-03-29T18:29:09.000000 |
| created_at | 2016-03-29T17:55:41.000000 |
| updated_at | b4502fe4-5a8e-410f-9faa-12774bcf655f |
| name | |

designate sends dns.pool.update events for updates to nameservers.

2016-03-29 11:29:09.263 42467 INFO searchlight.listener [-] event_type:dns.pool.update
2016-03-29 11:29:09.264 42467 INFO searchlight.listener [-] payload:{u'ns_records': [{u'created_at': u'2016-03-29T17:55:41.000000', u'hostname': u'', u'pool_id': u'794ccc2c-d751-44fe-b57f-8894c9f5c842', u'updated_at': u'2016-03-29T18:29:09.000000', u'priority': 10, u'version': 4, u'id': u'b4502fe4-5a8e-410f-9faa-12774bcf655f'}, {u'created_at': u'2016-03-29T18:29:09.000000', u'hostname': u'', u'pool_id': u'794ccc2c-d751-44fe-b57f-8894c9f5c842', u'updated_at': None, u'priority': 10, u'version': 1, u'id': u'165cea96-b05e-4028-852d-8febe1aea6d9'}], u'name': u'default', u'nameservers': [], u'tenant_id': None, u'created_at': u'2016-03-29T01:14:21.000000', u'updated_at': u'2016-03-29T18:29:08.000000', u'id': u'794ccc2c-d751-44fe-b57f-8894c9f5c842', u'version': 5, u'provisioner': u'UNMANAGED', u'attributes': [], u'also_notifies': [], u'targets': [], u'description': None}

Changed in searchlight:
importance: Undecided → Medium
Revision history for this message
Lakshmi N Sampath (lakshmi-sampath) wrote :

Related to same issue, the current OS::Designate::RecordSet document has "records" item(see below) which has a list of nameservers. This goes out of sync whenever a new nameserver is created in designate, since it only sends dns.poo.update event. The is no additional event for record "update". We need to check if we should update records in OS::Designate::RecordSet for every nameserver create/delete or just maintain a separate document type for nameservers.

            "_index": "searchlight-2016_03_29_19_02_27",
            "_type": "OS::Designate::RecordSet",
            "_id": "f884912f-da69-494f-98e5-d8a8d76153b4",
            "_score": 1,
            "_source": {
               "status": "PENDING",
               "zone_id": "2f647395-60dc-4949-9249-a5c6a03ce315",
               "description": null,
               "created_at": "2016-03-29T18:19:44.000000",
               "__searchlight-user-role": [
               "updated_at": "2016-03-29T18:19:44.000000",
               "_parent": "2f647395-60dc-4949-9249-a5c6a03ce315",
               "records": [
                     "data": ""
                     "data": ""
                     "data": ""
               "version": 3,
               "ttl": null,
               "action": "UPDATE",
               "project_id": "80264096ac454d3d904002491fafe2ec",
               "type": "NS",
               "id": "f884912f-da69-494f-98e5-d8a8d76153b4",
               "name": ""

Revision history for this message
Steve McLellan (sjmc7) wrote :

I'm told that we should expect recordset notifications if altering nameservers changes records, though on my system that doesn't seem to be the case. If so, i'll raise a bug with designate; don't think this requires work on our end.

Revision history for this message
Steve McLellan (sjmc7) wrote :
Revision history for this message
Davanum Srinivas (DIMS) (dims-v) wrote : Fix included in openstack/python-designateclient 2.2.0

This issue was fixed in the openstack/python-designateclient 2.2.0 release.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on searchlight (master)

Change abandoned by Trinh Nguyen (<email address hidden>) on branch: master

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers