'ntpq: read: Connection refused' on controllers while performing any query to NTPD from vrouter namespace using 'ntpq'

[Dennis Dmitriev]

Reproduced on CI (for example: http://jenkins-product.srt.mirantis.net:8080/job/7.0.system_test.ubuntu.thread_1/6/testReport/%28root%29/check_nodes_disks/check_nodes_disks/?)
, in the following system tests:

    ha_flat_addremove
    check_nodes_disks
    ha_one_controller_backup_restore
    backup_restore_ha_flat
    manual_cic_maintenance_mode
    auto_cic_maintenance_mode
    negative_manual_cic_maintenance_mode
    negative_auto_cic_maintenance_mode
    external_ntp_ha
    external_dns_ha

On Ubuntu controllers in any cluster configuration, the following error could appear:

root@node-1:~# ip netns exec vrouter ntpq -p
ntpq: read: Connection refused

This is happened because 'ntpq' is connected to NTPD using IPv6, but started by OCF script NTPD is using '-4' option and rejects all IPv6 requests.

Possible solutions:

 - remove '-4' option from OCF script ns_ntp. This option is not used for other nodes in cluster;

 - fix system tests and reflect in documentation that user use 'ntpq' by manually providing IPv4 address:

        root@node-1:~# ip netns exec vrouter ntpq -p 127.0.0.1
             remote refid st t when poll reach delay offset jitter
        ==============================================================================
         10.109.11.1 .INIT. 16 - - 1024 0 0.000 0.000 0.000

ISO version: {u'build_id': u'2015-06-24_16-12-23', u'build_number': u'15', u'auth_required': True, u'fuel-ostf_sha': u'69e7fa120e8efa7ed74d98efc63079d2f5c69d7b', u'fuel-library_sha': u'7d19bc3783177aebf64fa4c2ae20d845cbd5348f', u'nailgun_sha': u'b74f847ec89c4bff1addb830704206dc503125f0', u'openstack_version': u'2014.2.2-7.0', u'production': u'docker', u'api': u'1.0', u'python-fuelclient_sha': u'1b8574a7c4ea884862763a15c636b066d51f49e7', u'astute_sha': u'776157f722b13aff5f59bc098cf948793e6498ef', u'fuelmain_sha': u'3b866d2ff3091a60362327028085fa62fd16c5a0', u'feature_groups': [u'mirantis'], u'release': u'7.0', u'release_versions': {u'2014.2.2-7.0': {u'VERSION': {u'build_id': u'2015-06-24_16-12-23', u'build_number': u'15', u'fuel-library_sha': u'7d19bc3783177aebf64fa4c2ae20d845cbd5348f', u'nailgun_sha': u'b74f847ec89c4bff1addb830704206dc503125f0', u'fuel-ostf_sha': u'69e7fa120e8efa7ed74d98efc63079d2f5c69d7b', u'production': u'docker', u'api': u'1.0', u'python-fuelclient_sha': u'1b8574a7c4ea884862763a15c636b066d51f49e7', u'astute_sha': u'776157f722b13aff5f59bc098cf948793e6498ef', u'fuelmain_sha': u'3b866d2ff3091a60362327028085fa62fd16c5a0', u'feature_groups': [u'mirantis'], u'release': u'7.0', u'openstack_version': u'2014.2.2-7.0'}}}}

[Stanislaw Bogatkin (sbogatkin)]

I actually wonder why we use some ipv6 stuff if we don't have any settings and mentions about it in Fuel. So, listening on ipv4 only seems good to me, cause there is no support of ipv6 in whole product.
In other side, enabling ipv6 is not a big problem - we just should do things carefully and look for possible problems with it.

[Dennis Dmitriev (ddmitriev)]

https://review.openstack.org/#/c/196675/