Software to automate the management and configuration of any infrastructure or application at scale. Get access to the Salt software package repository here:
The _subnetnames and _subnetids parameters of the salt.states.boto_vpc.route_table_present method overwrite the existing subnet associations of the route table.
That means that if you have a state file that..
creates vpc
creates internet gateway
creates route table
creates subnets (and specify the route table)
This will create all of the objects just fine. However, if you run it again, the third step will remove all subnet associations from the route table, and then the fourth step will add them back.
This creates a hard dependency on the order in which the objects are created. You MUST create the subnets first and then, and only then, can you create the route table. Also, the route table state file must be updated to include the names/ids of any subnets that you try to create.
This also renders the "route_table_name" parameter of "subnet_present" useless.
It also makes it impossible to encapsulate the networking and application objects in a single set of state files. The creation of your route table + subnets MUST be a monolithic state file, which limits its usefulness.
I've put this as a bug, rather than an enhancement mostly because this behavior makes subnet_present::route_table_name useless if you're enforcing state with route_table_present. Otherwise, I would probably have raised this as an enhancement.
And now all of the subnets have been re-associated with the route table.
Expected behavior
I would not expect the second execution of the state file to generate any changes.
Suggested solutions:
the route_tablepresent::subnet* params to be additive, rather than absolute, and then add an "overwrite_subnets={True, FALSE}" (and update the documentation to reflect the behavior change)
Add additional parameters (like salt.states.group does for group membership)
My personal preference is the first option rather than the second because it seems to be more intuitive to me - the addition of the "overwrite_subnets" makes the behavior explicit. Where as the second option creates bloat (IMHO).
There are probably other options that I've not thought about but those two are what immediately came to mind.
Description
The _subnetnames and _subnetids parameters of the salt.states.boto_vpc.route_table_present method overwrite the existing subnet associations of the route table.
That means that if you have a state file that..
This will create all of the objects just fine. However, if you run it again, the third step will remove all subnet associations from the route table, and then the fourth step will add them back.
This creates a hard dependency on the order in which the objects are created. You MUST create the subnets first and then, and only then, can you create the route table. Also, the route table state file must be updated to include the names/ids of any subnets that you try to create.
This also renders the "route_table_name" parameter of "subnet_present" useless.
It also makes it impossible to encapsulate the networking and application objects in a single set of state files. The creation of your route table + subnets MUST be a monolithic state file, which limits its usefulness.
I've put this as a bug, rather than an enhancement mostly because this behavior makes subnet_present::route_table_name useless if you're enforcing state with route_table_present. Otherwise, I would probably have raised this as an enhancement.
Setup
Setup Script
``` cat <Steps to Reproduce the behavior
Run the following twice:
On the second run, you will see this...
Notice how the subnet associations have been deleted. This is going to cause a very brief network outage for all subnets in this routing table
And now all of the subnets have been re-associated with the route table.
Expected behavior
I would not expect the second execution of the state file to generate any changes.
Suggested solutions:
My personal preference is the first option rather than the second because it seems to be more intuitive to me - the addition of the "overwrite_subnets" makes the behavior explicit. Where as the second option creates bloat (IMHO).
There are probably other options that I've not thought about but those two are what immediately came to mind.
Versions Report
NOTE: I have applied https://github.com/saltstack/salt/commit/32ed7d05f0af1f07a0144cf5594370a5d65e70b3 to be able to create the routing tables in my sample script.
salt --versions-report
(Provided by running salt --versions-report. Please also mention any differences in master/minion versions.) ``` Salt Version: Salt: 3002.5 Dependency Versions: cffi: 1.14.5 cherrypy: unknown dateutil: 2.8.1 docker-py: Not Installed gitdb: 0.6.4 gitpython: 1.0.1 Jinja2: 2.11.1 libgit2: Not Installed M2Crypto: 0.35.2 Mako: Not Installed msgpack: 0.6.2 msgpack-pure: Not Installed mysql-python: Not Installed pycparser: 2.20 pycrypto: Not Installed pycryptodome: 3.10.1 pygit2: Not Installed Python: 3.6.8 (default, Nov 16 2020, 16:55:22) python-gnupg: Not Installed PyYAML: 3.13 PyZMQ: 17.0.0 smmap: 0.9.0 timelib: Not Installed Tornado: 4.5.3 ZMQ: 4.1.4 System Versions: dist: centos 7 Core locale: UTF-8 machine: x86_64 release: 3.10.0-957.1.3.el7.x86_64 system: Linux version: CentOS Linux 7 Core ```