# Revision history [back]

### OS::Heat::ResourceGroup resources modified in unexpected order

In my OpenStack configuration, I am using Heat to create projects and then associate several networks with those projects. Here is a rough example of the initial parameter file I am using:

parameters:
project: Example_project_name
networks:
- { name: net0, size: 28 }
- { name: net1, size: 28 }
- { name: net2, size: 28 }


In order to create multiple network resources, I am taking advantage of OS::Heat::ResourceGroup. This works perfectly fine upon creation. Additionally, you can add and remove networks freely from the end of the list and update the Heat stack.

However, I noticed some odd behavior when trying to add or remove networks from the _middle_ of the list. To illustrate this, let's say that I created a Heat stack using the above configuration. I'd end up with some Heat resources that look like this:

|-----------------------------------------|
|  OpenStack Item    |    Heat Resource   |
|-----------------------------------------|
|        net0        |    HeatNetwork[0]  |
|-----------------------------------------|
|        net1        |    HeatNetwork[1]  |
|-----------------------------------------|
|        net2        |    HeatNetwork[2]  |
|-----------------------------------------|


For argument's sake, let's say I then remove "net0" from the original parameter file, and attempt to update the Heat stack. Here's what I expect to happen:

|-----------------------------------------|
|  OpenStack Item    |    Heat Resource   |
|-----------------------------------------|
|        net1        |    HeatNetwork[1]  |
|-----------------------------------------|
|        net2        |    HeatNetwork[2]  |
|-----------------------------------------|


However, here's what _actually_ happens:

|-----------------------------------------|
|  OpenStack Item    |    Heat Resource   |
|-----------------------------------------|
|        net1        |    HeatNetwork[0]  |
|-----------------------------------------|
|        net2        |    HeatNetwork[1]  |
|-----------------------------------------|


As you can see, upon update in this scenario, Heat simply deletes the most recently created resource, and tries to "shift" the data from the remaining networks onto the old resources. This is unacceptable because I have properties in the "HeatNetwork" resources that must remain immutable. This causes the the stack update to fail.

My question is, is there a way around this by keeping all of these attributes as immutable? One solution I thought of would be to delete _all_ of the HeatNetwork resources at once and recreate them. Unfortunately, as far as I've been able to tell, there is no functionality in Heat that currently supports this (in my version at least, which is the Mitaka version, 6.1.2). Can anyone please advise what to do here? Could this be a bug that can be fixed upstream?