Bug 1350422
| Summary: | [OSP7] Backport of Bug #1416994 (nova vnc server listens on all active interfaces) | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Ondrej <ochalups> |
| Component: | openstack-tripleo-heat-templates | Assignee: | Ollie Walsh <owalsh> |
| Status: | CLOSED ERRATA | QA Contact: | Aharon Canan <acanan> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 7.0 (Kilo) | CC: | afariasa, afazekas, aschultz, augol, awaugama, dasmith, dcadzow, dmacpher, ealcaniz, jcoufal, jstransk, lyarwood, mburns, mcornea, morazi, owalsh, rhel-osp-director-maint, srevivo, tvvcox |
| Target Milestone: | zstream | Keywords: | FeatureBackport, Triaged, ZStream |
| Target Release: | 7.0 (Kilo) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-tripleo-heat-templates-0.8.6-139.el7ost | Doc Type: | Bug Fix |
| Doc Text: |
The OpenStack Compute (nova) VNC server used a hardcoded value (0.0.0.0), which allowed access on all active interface. This fix allows you to change the value through the director's Heat template collection.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-07-05 12:26:45 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1431674 | ||
| Bug Blocks: | |||
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 |
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: