nova-compute-proxy charm does not enable security group.

[bugproxy]

#===========================================================
The Frobisher Nova nodes which instantiated by Openstack via the nova-compute-proxy charm does not enable the security group.

By some investigation, I found the this compute node configuration created by Juju. It set security group as false.
[root@zs93k24 ~]# cat cat /etc/neutron/plugins/ml2/openvswitch_agent.ini
cat: cat: No such file or directory
# mitaka
###############################################################################
# [ WARNING ]
# Configuration file maintained by Juju. Local changes may be overwritten.
# Config generated by nova-compute-proxy charm
###############################################################################
[ovs]
enable_tunneling = True
local_ip = xx.xx.xx.xx
bridge_mappings =

[agent]
tunnel_types = gre
l2_population = False
enable_distributed_routing = False
prevent_arp_spoofing = True

[securitygroup]
enable_security_group = False
[root@zs93k24 ~]#

But we did not disable security group on the juju config side.

(env) liwbj@zs95k5:~/.ssh$ juju config nova-compute-proxy
application: nova-compute-proxy
charm: nova-compute-proxy
settings:
  disable-security-groups:
    default: true
    description: |
      Disable neutron based security groups - setting this configuration option
      will override any settings configured via the neutron-api charm.
      .
      BE CAREFUL - this option allows you to disable all port level security within
      an OpenStack cloud.
    type: boolean
    value: false

I checked the source code of juju
(env) liwbj@zs95k5:/home/vance/juju/git/charm-nova-compute-proxy/templates/mitaka$ cat openvswitch_agent.ini
# mitaka
.....................
[securitygroup]
{% if neutron_security_groups -%}
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver
{% else -%}
enable_security_group = False
{% endif -%}

(env) liwbj@zs95k5:~/.ssh$ juju config neutron-api neutron-security-groups
true
(env) liwbj@zs95k5:~/.ssh$

I think the juju configuration is correct, but got the incorrect result.

Could you help me take a look for this issue? If you need more bug information, please let me know.

#=== Steps to Reproduce ====================================
#===========================================================
1. Deploy OpenStack control plane via Canonical distribution (Juju)
2. Deploy at least 2 Frobisher zKVM compute nodes via nova-compute-proxy charm
3. Check the /etc/neutron/plugins/ml2/openvswitch_agent.ini file

#=== Host Details ==========================================
#===========================================================
# hostname -f

# cat /etc/system-release

# Add dbginfo and other related log files.

[root@zs93k24 ~]# hostname -f
zs93k24
[root@zs93k24 ~]#
[root@zs93k24 ~]# cat /etc/system-release
KVM for IBM z Systems release 1.1.3-beta4.3 (Z)
[root@zs93k24

== =========================== 2016-12-19 01:05:39 ==
I found that Juju has ability to change the configuration on openvswitch_agent.ini.I did some test as below.

Manually change the openvswitch_agent.ini to enable enable_security_group = True
Then modify the juju config to false

(env) liwbj@zs95k5:~$ juju config neutron-api neutron-security-groups=true
WARNING the configuration setting "neutron-security-groups" already has the value "true"
(env) liwbj@zs95k5:~$ juju config neutron-api neutron-security-groups=false
(env) liwbj@zs95k5:~$ juju config neutron-api neutron-security-groups
false
(env) liwbj@zs95k5:~$ juju status

Then I can find the openvswitch_agent.ini was changed by juju
[root@zs93k24 ml2]# cat /etc/neutron/plugins/ml2/openvswitch_agent.ini | grep security
[securitygroup]
enable_security_group = False
[root@zs93k24 ml2]#

On opposite way, I manually changed enable_security_group = True on openvswitch_agent.ini

[root@zs93k24 ml2]# cat openvswitch_agent.ini
# mitaka
###############################################################################
# [ WARNING ]
# Configuration file maintained by Juju. Local changes may be overwritten.
# Config generated by nova-compute-proxy charm
###############################################################################
[ovs]
enable_tunneling = True
local_ip = 10.20.95.79
bridge_mappings =

[agent]
tunnel_types = gre
l2_population = False
enable_distributed_routing = False
prevent_arp_spoofing = True

[securitygroup]
enable_security_group = True
firewall_driver = neutron.agent.linux.iptables_firewall.OVSHybridIptablesFirewallDriver

[root@zs93k24 ml2]#

Set the juju config is also true

(env) liwbj@zs95k5:~$ juju config neutron-api neutron-security-groups=true
(env) liwbj@zs95k5:~$ juju config neutron-api neutron-security-groups
true
(env) liwbj@zs95k5:~$ juju status

But juju also changed openvswitch_agent.ini as false.

[root@zs93k24 ml2]# cat /etc/neutron/plugins/ml2/openvswitch_agent.ini | grep security
[securitygroup]
enable_security_group = False
[root@zs93k24 ml2]#

So the conclusion is that no matter what do I set on juju config, juju will set enable_security_group = False on openvswitch_agent.ini.

================================== 2016-12-19 04:36:44 ==
There are two issues regarding security group settings with the nova compute proxy:

a) changing the charm value is not changing the agent.ini value, and
b) the charm default should be to enable security groups

so it seems like the juju charm configs can be updated successfully, but the changed config is not refelcted in the openvswitch_agent.ini.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-12-19 08:52 EDT-------
Canonical please assign to the right component

Target project nova-compute-proxy charm:
https://bugs.launchpad.net/charm-nova-compute-proxy

Many thanks

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2016-12-20 08:44 EDT-------
*** Bug 149927 has been marked as a duplicate of this bug. ***

[James Page (james-page)]

The security group setting is provided from the neutron-api charm via its security-groups setting, so this feels like a missing bit of data in the context that is used to generate the configuration file.

[Andrew McLeod (admcleod)]

I'm currently investigating this issue in a test environment.

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-09-13 03:51 EDT-------
IBM bugzilla status -> closed.. will not be requested anymore

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2017-09-13 04:08 EDT-------
Re-opened , still under investigation by Canonical

[bugproxy (bugproxy)]

------- Comment From <email address hidden> 2018-02-07 05:44 EDT-------
IBM bugzilla status -> closed, will not be fixed, not required anymore