cross-reference of heat resources/attributes fails with circular dependency.

[Guoping Jia]

The cross reference of Heat resources / attributes raises a CircularDependencyException and therefore fails.

Here is the use case:

- create 2 security groups, each group exposes its own (restricted) ports;
- add "group" roles for a cluster of instances to allow the 2 security groups to communicate;

This works well using nova and/or neutron CLI. However, with HOT using OS::Neutron::SecurityGroup, the heat stack-create fails with the circular dependency:

"ERROR: Remote error: CircularDependencyException Circular Dependency Found: {CinderVolumeAttachment "volume_attachment": {Server "instance"}, SecurityGroup "security_group_1": {SecurityGroup "security_group_2"}, SecurityGroup "security_group_2": {SecurityGroup "security_group_1"}, Port "server_port": {SecurityGroup "security_group_1"}, Server "instance": {Port "server_port"}, FloatingIP "floating_ip": {Port "server_port"}}"

[Thomas Herve (therve)]

Can you share the template? It's possible there is a different way of doing this.

[Guoping Jia (guoping-jia)]

Attaching the heat template.

[Anant Patil (ananta)]

The security groups refer to each other in the template, and cause circular reference. Heat wouldn't know which ones to create first, and hence it bails out with the Circular Reference exception. Not sure if we can re-write this template in a way that we avoid circular reference, I will leave it to the experts. Other possible solutions could be to (1) First create the stack with security groups and then take the physical resource ids of security groups and update the template and update the stack; (2) In heat we add a new resource OS::Neutron::AddSGRules, which will give the template authors the flexibility to add SG rules in same template.

[Thomas Herve (therve)]

So yeah that issue still remains. We solved the self-referencing problem, if you specify nothing in the group_id, but I don't think we have a solution yet for cross reference. https://blueprints.launchpad.net/heat/+spec/securitygroupingressegress is probably the solution, ie new resources to handle that (ie SecurityGroupRule resource).

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/330608
Committed: https://git.openstack.org/cgit/openstack/heat/commit/?id=236ee7e6b4f4c14657586abc34bff370dc6cde1d
Submitter: Jenkins
Branch: master

commit 236ee7e6b4f4c14657586abc34bff370dc6cde1d
Author: Dmitriy Uvarenkov <email address hidden>
Date: Wed Jun 15 11:00:27 2016 +0300

    Add new resource Security Group Rule

    As for now rules are a property of security group
    resource. The problem is that rules can contain
    security group id's as their parameters. This
    leads to circular dependencies.

    Now you can create security groups as before but also
    create new rules as separate resources and add them to
    security groups.

    Closes-Bug: #1581447
    Implements bp securitygroupingressegress
    Change-Id: I3425960e3d5a63c54b0c6739e305a53780075095

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/heat 7.0.0.0b3 development milestone.