| 2016-09-22 16:07:30 |
Zane Bitter |
description |
RouterGateways depend on any RouterInterface attached to the same Router. Originally this was checked simply by looking up the `router_id` property of the RouterInterface and comparing it to the `router_id` property of the RouterGateway.
This changed in https://review.openstack.org/#/c/235426/2/heat/engine/resources/openstack/neutron/router.py to do a lookup from the Neutron API of the RouterInterface's `router` property (which may be either a name or a UUID, but it returns a UUID). Doing API calls is very expensive and calculating dependencies is supposed to be something that is very cheap.
IMHO doing a lookup on the API is pointless anyway. The RouterGateway resource takes only a `router_id` (UUID), so the template author will either:
* Create the router in the template and use get_resource (in this case both the RouterGateway and the RouterInterface get passed a UUID for the router, so we can just directly compare them - but see below); OR
* Pass the router UUID in as a parameter and use get_param (in this case both the RouterGateway and the RouterInterface get passed a UUID for the router, so we can just directly compare them).
What they will approximately never do is pass in both the router UUID and router name as parameters and use the name for the `router` property in RouterInterface and the UUID for the `router_id` property in RouterGateway, so that we can't directly compare them without first resolving the name using the Neutron API.
IMHO unconditionally adding in an expensive API call to solve this total non-issue is crazy. The fix should be just to go back to essentially what we were doing before.
The same thing applies to OS::Neutron::ExtraRoute: https://review.openstack.org/#/c/235426/2/heat/engine/resources/openstack/neutron/extraroute.py
See further discussion in https://review.openstack.org/#/c/289371/ for context. |
RouterGateways depend on any RouterInterface attached to the same Router. Originally this was checked simply by looking up the `router_id` property of the RouterInterface and comparing it to the `router_id` property of the RouterGateway.
This changed in https://review.openstack.org/#/c/235426/2/heat/engine/resources/openstack/neutron/router.py to do a lookup from the Neutron API of the RouterInterface's `router` property (which may be either a name or a UUID, but it returns a UUID). Doing API calls is very expensive and calculating dependencies is supposed to be something that is very cheap.
IMHO doing a lookup on the API is pointless anyway. The RouterGateway resource takes only a `router_id` (UUID), so the template author will either:
* Create the router in the template and use get_resource (in this case both the RouterGateway and the RouterInterface get passed a UUID for the router, so we can just directly compare them - but see below); OR
* Pass the router UUID in as a parameter and use get_param (in this case both the RouterGateway and the RouterInterface get passed a UUID for the router, so we can just directly compare them).
What they will approximately never do is pass in both the router UUID and router name as parameters and use the name for the `router` property in RouterInterface and the UUID for the `router_id` property in RouterGateway, so that we can't directly compare them without first resolving the name using the Neutron API.
IMHO unconditionally adding in an expensive API call to solve this total non-issue is crazy. The fix should be just to go back to essentially what we were doing before https://review.openstack.org/#/c/235426/ (except referencing `router` instead of `router_id`),
The same thing applies to OS::Neutron::ExtraRoute: https://review.openstack.org/#/c/235426/2/heat/engine/resources/openstack/neutron/extraroute.py
See further discussion in https://review.openstack.org/#/c/289371/ for context. |
|
