Add support for updating AWS routing table entries #37
Conversation
The `advertised_instance_routes` cloud property on resource pools/vm
types has been added to allow manifests to connect routes on AWS
Routing Tables with specific instances, if you need to route traffic
through a BOSH deployed VM (like in the case of a site-to-site VPN).
If using this, it is recommended to only have a single instance of a
single job of that resource pool, to avoid confusion. If there are
multiple instances/jobs in the resource pool, the last one processed
will be the node assigned to the route.
Datastructure of `advertised_instance_routes` is as follows:
```
cloud_properties:
advertised_instance_routes:
- table_id: rt-abcdef123
destination: 10.0.0.0/16
- table_id: rt 12345abcd
destination: 10.0.0.0/16
```
This allows the manifest to specify that multiple routing tables
are updated to send the destination route(s) to it. Once removed
from the manifest, the routes will remain, but once the VM is recreated,
the route will become a black hole in the AWS routing table, and cease
to work.
|
Hey geofffranks! Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA. |
| @logger.debug("Sending traffic for '#{definition["destination"]}' to '#{@aws_instance.id}' in '#{definition["table_id"]}'") | ||
|
|
||
| existing = false | ||
| table.routes.each do |route| |
There was a problem hiding this comment.
Docs say routes is a normal array, so could probably shorten this to: existing = table.routes.any ...
|
Oh, that's an interesting idea. Hadn't considered this sort of thing as a CPI property before, just as a co-located release sort of thing. Wonder what CPI team thinks of this approach. |
|
@dpb587 api already talks to the iaas so might as well have it here instead of connecting from somewhere else. it's logged, diffed via cloud properties, audited through events, etc. |
|
@geofffranks neat feature! Looks good, my only feedback is seems a little messy to not delete the route when we delete the VM. Do you see any issues with calling |
|
Cool - I'll look forward to using it! |
|
@ljfranklin black holes are not bad. just means not configured. i think we should make as little api calls as possible. cc @geofffranks |
|
I can add the delete feature, and clean up the check for existing routes. Thanks for the quick feedback!
|
|
Just saw @cppforlife 's note about maybe not deleting. Let me know which way you want to go. |
|
@cppforlife @geofffranks If I'm relying on BOSH to create a route for me, my expectation would be for BOSH to also remove that route when that VM goes away. I could imagine an initial setup with a fallback route |
|
@geofffranks Build failed on integration tests due to rubygems flakiness. Restarted. |
The
advertised_instance_routescloud property on resource pools/vmtypes has been added to allow manifests to connect routes on AWS
Routing Tables with specific instances, if you need to route traffic
through a BOSH deployed VM (like in the case of a site-to-site VPN).
If using this, it is recommended to only have a single instance of a
single job of that resource pool, to avoid confusion. If there are
multiple instances/jobs in the resource pool, the last one processed
will be the node assigned to the route.
Datastructure of
advertised_instance_routesis as follows:This allows the manifest to specify that multiple routing tables
are updated to send the destination route(s) to it. Once removed
from the manifest, the routes will remain, but once the VM is recreated,
the route will become a black hole in the AWS routing table, and cease
to work.