Description of problem: Hello, currently it is not possible to set vncserver_listen attribute, as it's hardcoded and passed in puppet. puppet/manifests/overcloud_compute.pp .. if $nova_ipv6 { $vncserver_listen = '::0' } else { $vncserver_listen = '0.0.0.0' } class { '::nova::compute::libvirt' : vncserver_listen => $vncserver_listen, ... Can it be made customizable and passed with ExtraConfig by heat-templates? Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: vncserver_listen hardcoded to default 0.0.0.0 Expected results: vncserver_listen can be set and passed with heat-templates Additional info:
From the customer: The following patch has worked for me: diff -ur orig/puppet/compute-puppet.yaml new/puppet/compute-puppet.yaml --- orig/puppet/compute-puppet.yaml 2016-07-06 13:04:03.660742178 +0200 +++ new/puppet/compute-puppet.yaml 2016-07-06 13:04:31.198455818 +0200 @@ -405,6 +405,7 @@ nova_enable_rbd_backend: {get_input: nova_enable_rbd_backend} nova_password: {get_input: nova_password} nova::compute::vncserver_proxyclient_address: {get_input: nova_vnc_proxyclient_address} + nova::compute::libvirt::vncserver_listen: {get_input: nova_vnc_proxyclient_address} nova::vncproxy::common::vncproxy_protocol: {get_input: nova_vncproxy_protocol} nova::vncproxy::common::vncproxy_host: {get_input: nova_vncproxy_host} nova::vncproxy::common::vncproxy_port: {get_input: nova_vncproxy_port} diff -ur orig/puppet/hieradata/compute.yaml new/puppet/hieradata/compute.yaml --- orig/puppet/hieradata/compute.yaml 2016-07-06 13:02:23.141486983 +0200 +++ new/puppet/hieradata/compute.yaml 2016-07-06 13:02:31.957035564 +0200 @@ -6,9 +6,7 @@ nova::compute::instance_usage_audit: true nova::compute::instance_usage_audit_period: 'hour' nova::compute::vnc_enabled: true - -nova::compute::libvirt::vncserver_listen: '0.0.0.0' -nova::compute::libvirt::migration_support: true +nova::compute::libvirt::migration_support: false nova::compute::rbd::libvirt_rbd_secret_uuid: "%{hiera('ceph::profile::params::fsid')}" diff -ur orig/puppet/manifests/overcloud_compute.pp new/puppet/manifests/overcloud_compute.pp --- orig/puppet/manifests/overcloud_compute.pp 2016-07-06 13:05:26.849918943 +0200 +++ new/puppet/manifests/overcloud_compute.pp 2016-07-06 13:05:42.479891578 +0200 @@ -91,15 +91,7 @@ package {'nfs-utils': } -> Service['nova-compute'] } -$nova_ipv6 = str2bool(hiera('nova::use_ipv6', false)) -if $nova_ipv6 { - $vncserver_listen = '::0' -} else { - $vncserver_listen = '0.0.0.0' -} -class { '::nova::compute::libvirt' : - vncserver_listen => $vncserver_listen, -} +class { '::nova::compute::libvirt' : } include ::nova::network::neutron include ::neutron I have been able to deploy RHOSP7.3.1 using this patch and I see that /etc/nova/nova.conf in compute nodes is properly configured. Is it possible to validate it from Engineering?
(In reply to Edu Alcaniz from comment #2) > From the customer: > > The following patch has worked for me: > > diff -ur orig/puppet/compute-puppet.yaml new/puppet/compute-puppet.yaml > --- orig/puppet/compute-puppet.yaml 2016-07-06 13:04:03.660742178 +0200 > +++ new/puppet/compute-puppet.yaml 2016-07-06 13:04:31.198455818 +0200 > @@ -405,6 +405,7 @@ > nova_enable_rbd_backend: {get_input: > nova_enable_rbd_backend} > nova_password: {get_input: nova_password} > nova::compute::vncserver_proxyclient_address: {get_input: > nova_vnc_proxyclient_address} > + nova::compute::libvirt::vncserver_listen: {get_input: > nova_vnc_proxyclient_address} > nova::vncproxy::common::vncproxy_protocol: {get_input: > nova_vncproxy_protocol} > nova::vncproxy::common::vncproxy_host: {get_input: > nova_vncproxy_host} > nova::vncproxy::common::vncproxy_port: {get_input: > nova_vncproxy_port} > diff -ur orig/puppet/hieradata/compute.yaml new/puppet/hieradata/compute.yaml > --- orig/puppet/hieradata/compute.yaml 2016-07-06 13:02:23.141486983 +0200 > +++ new/puppet/hieradata/compute.yaml 2016-07-06 13:02:31.957035564 +0200 > @@ -6,9 +6,7 @@ > nova::compute::instance_usage_audit: true > nova::compute::instance_usage_audit_period: 'hour' > nova::compute::vnc_enabled: true > - > -nova::compute::libvirt::vncserver_listen: '0.0.0.0' > -nova::compute::libvirt::migration_support: true > +nova::compute::libvirt::migration_support: false Not clear why migration_support been changed. IIRC vncserver_listen was initially set to '0.0.0.0' as this was necessary for migration to work (since been resolved). Is this workaround disabling migration because it breaks it? > > nova::compute::rbd::libvirt_rbd_secret_uuid: > "%{hiera('ceph::profile::params::fsid')}" > > diff -ur orig/puppet/manifests/overcloud_compute.pp > new/puppet/manifests/overcloud_compute.pp > --- orig/puppet/manifests/overcloud_compute.pp 2016-07-06 > 13:05:26.849918943 +0200 > +++ new/puppet/manifests/overcloud_compute.pp 2016-07-06 > 13:05:42.479891578 +0200 > @@ -91,15 +91,7 @@ > package {'nfs-utils': } -> Service['nova-compute'] > } > > -$nova_ipv6 = str2bool(hiera('nova::use_ipv6', false)) > -if $nova_ipv6 { > - $vncserver_listen = '::0' > -} else { > - $vncserver_listen = '0.0.0.0' > -} > -class { '::nova::compute::libvirt' : > - vncserver_listen => $vncserver_listen, > -} Would causing a regression of https://bugzilla.redhat.com/show_bug.cgi?id=1300678. > +class { '::nova::compute::libvirt' : } > include ::nova::network::neutron > include ::neutron > > I have been able to deploy RHOSP7.3.1 using this patch and I see that > /etc/nova/nova.conf in compute nodes is properly configured. > > > Is it possible to validate it from Engineering?
(In reply to Ollie Walsh from comment #12) > (In reply to Edu Alcaniz from comment #2) > > From the customer: > > > > The following patch has worked for me: > > > > diff -ur orig/puppet/compute-puppet.yaml new/puppet/compute-puppet.yaml > > --- orig/puppet/compute-puppet.yaml 2016-07-06 13:04:03.660742178 +0200 > > +++ new/puppet/compute-puppet.yaml 2016-07-06 13:04:31.198455818 +0200 > > @@ -405,6 +405,7 @@ > > nova_enable_rbd_backend: {get_input: > > nova_enable_rbd_backend} > > nova_password: {get_input: nova_password} > > nova::compute::vncserver_proxyclient_address: {get_input: > > nova_vnc_proxyclient_address} > > + nova::compute::libvirt::vncserver_listen: {get_input: > > nova_vnc_proxyclient_address} > > nova::vncproxy::common::vncproxy_protocol: {get_input: > > nova_vncproxy_protocol} > > nova::vncproxy::common::vncproxy_host: {get_input: > > nova_vncproxy_host} > > nova::vncproxy::common::vncproxy_port: {get_input: > > nova_vncproxy_port} > > diff -ur orig/puppet/hieradata/compute.yaml new/puppet/hieradata/compute.yaml > > --- orig/puppet/hieradata/compute.yaml 2016-07-06 13:02:23.141486983 +0200 > > +++ new/puppet/hieradata/compute.yaml 2016-07-06 13:02:31.957035564 +0200 > > @@ -6,9 +6,7 @@ > > nova::compute::instance_usage_audit: true > > nova::compute::instance_usage_audit_period: 'hour' > > nova::compute::vnc_enabled: true > > - > > -nova::compute::libvirt::vncserver_listen: '0.0.0.0' > > -nova::compute::libvirt::migration_support: true > > +nova::compute::libvirt::migration_support: false > > Not clear why migration_support been changed. IIRC vncserver_listen was > initially set to '0.0.0.0' as this was necessary for migration to work > (since been resolved). Is this workaround disabling migration because it > breaks it? > > > > > nova::compute::rbd::libvirt_rbd_secret_uuid: > > "%{hiera('ceph::profile::params::fsid')}" > > > > diff -ur orig/puppet/manifests/overcloud_compute.pp > > new/puppet/manifests/overcloud_compute.pp > > --- orig/puppet/manifests/overcloud_compute.pp 2016-07-06 > > 13:05:26.849918943 +0200 > > +++ new/puppet/manifests/overcloud_compute.pp 2016-07-06 > > 13:05:42.479891578 +0200 > > @@ -91,15 +91,7 @@ > > package {'nfs-utils': } -> Service['nova-compute'] > > } > > > > -$nova_ipv6 = str2bool(hiera('nova::use_ipv6', false)) > > -if $nova_ipv6 { > > - $vncserver_listen = '::0' > > -} else { > > - $vncserver_listen = '0.0.0.0' > > -} > > -class { '::nova::compute::libvirt' : > > - vncserver_listen => $vncserver_listen, > > -} > > Would causing a regression of > https://bugzilla.redhat.com/show_bug.cgi?id=1300678. Actually no, it would be set to nova_vnc_proxyclient_address which should be correct for IPv6 deployments > > > +class { '::nova::compute::libvirt' : } > > include ::nova::network::neutron > > include ::neutron > > > > I have been able to deploy RHOSP7.3.1 using this patch and I see that > > /etc/nova/nova.conf in compute nodes is properly configured. > > > > > > Is it possible to validate it from Engineering?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2130