Expose port-security knob for all network ports (connection points)

[Sridhar Ramaswamy]

Tacker currently automatically sets "port_security_enabled" flag to False for some ports,

- ports that are marked as "management"
- ports with static IP address assigned

For other simple ports specifications the port_security_enabled flag is unspecified and hence defaults to True. Beyond the fact that this is inconsistent which needs to be fixed, we to expose an attribute for Tacker VNFD to explicit model it in the TOSCA template.

Something like,

DataCP:
    type: tosca.nodes.nfv.CP
    properties:
      anti_spoof_protection: [true | false]

Note from Sripriya:

looks like port-security-enabled can be set at network level as well,

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Neutron::Net-hot

.. which changes the default value of all ports created in that neutron network. So a similar flag can be introduced in VirtualLink as well,

InternalVL:
  type: tosca.nodes.nfv.VL
  properties:
      cidr: 10.10.1.0/24
      gateway: 10.10.1.1
      anti_spoof_protection: [true | false]

[Bob Haddleton (bob-haddleton)]

If the property name matches the Heat property name exactly, it will be mapped through to the OS::Neutron::Port object by heat-translator with no additional translation required. If the property name does not match the Heat property name, it will need to be modified by Tacker either before or after the HOT template is created by heat-translator.

So it might be easier to just make the property name "port_security_enabled", though it does raise the larger issue of tying the TOSCA node definition too closely to Heat. On the other hand, using different names for properties just because they are different than what Heat uses doesn't make a lot of sense either. I'm not making the argument either way, just wanted to lay out the two scenarios.

[Sridhar Ramaswamy (srics-r)]

Thanks for the explanation. As you might have realized, TOSCA takes an intent based approach to naming these properties. So keeping it 'port_security_enabled' is not an option.

Current proposed syntax is,

 DataCP:
    type: tosca.nodes.nfv.CP
    properties:
        anti_spoof_protection: [True | False]

[Sridhar Ramaswamy (srics-r)]

Bob - assigning this to you based on the last weekly meeting discussion on absorbing this along with TOSCA parser work.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/306271

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/306271
Committed: https://git.openstack.org/cgit/openstack/tacker/commit/?id=801896e976a8432baea69ac1e3def08a135ca09c
Submitter: Jenkins
Branch: master

commit 801896e976a8432baea69ac1e3def08a135ca09c
Author: Sripriya <email address hidden>
Date: Fri Apr 15 00:15:18 2016 -0700

    Support port_security_enabled for Heat Kilo ver

    This fix supports port_security_enabled attr for Heat Kilo version.
    Also adds the new attr to tosca templates.

    Change-Id: I6c1e93e00dce0a6a7aa6d2a1f09970d3564524be
    Closes-Bug: #1566003
    Closes-Bug: #1547284

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/mitaka
Review: https://review.openstack.org/308587

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/308587
Committed: https://git.openstack.org/cgit/openstack/tacker/commit/?id=bea76d90a9c19e5dbdc792897bc504ce25a4f7e8
Submitter: Jenkins
Branch: stable/mitaka

commit bea76d90a9c19e5dbdc792897bc504ce25a4f7e8
Author: Sripriya <email address hidden>
Date: Fri Apr 15 00:15:18 2016 -0700

    Support port_security_enabled for Heat Kilo ver

    This fix supports port_security_enabled attr for Heat Kilo version.
    Also adds the new attr to tosca templates.

    Change-Id: I6c1e93e00dce0a6a7aa6d2a1f09970d3564524be
    Closes-Bug: #1566003
    Closes-Bug: #1547284
    (cherry picked from commit 801896e976a8432baea69ac1e3def08a135ca09c)

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/tacker 0.3.1 release.

[Doug Hellmann (doug-hellmann)]

This issue was fixed in the openstack/tacker 0.4.0 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/tacker 0.3.1 release.