Ask Your Question
1

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

asked 2018-07-11 18:46:53 -0600

rich.gold gravatar image

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?

Thanks in advance.

edit retag flag offensive close merge delete

1 answer

Sort by ยป oldest newest most voted
1

answered 2018-11-26 13:18:34 -0600

zaneb gravatar image

You can use the removal_policies property to blacklist an index (corresponding to the entry you remove from the input list).

Note that in Mitaka there's no way to reuse this index again once you've blacklisted it. (In Queens and later you can do this by setting the removal_policies_mode.)

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Get to know Ask OpenStack

Resources for moderators

Question Tools

1 follower

Stats

Asked: 2018-07-11 18:46:53 -0600

Seen: 87 times

Last updated: Nov 26 '18