Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform Resources are modular-only, there is no allowance for nested creation.
This means every end-user must use in sequence:
ibm_is_lb(5-10 minutes provision time)
ibm_is_lb_pool(~4 minutes provision time, as a new pool will cause update/scan of the LB instance)
ibm_is_lb_pool_member for HA Pair Node A (~4 minutes provision time, as a new pool will cause LB update/scan )
ibm_is_lb_pool_member for HA Pair Node B (~4 minutes provision time, as a new pool will cause LB update/scan)
ibm_is_lb_listener(~4 minutes provision time, as a new pool will cause update/scan of the LB instance)
Therefore, creating just 1 listener (e.g. Port 443) and 1 pool (with 2 pool server members) will take approximately 5 + 16 minutes using Terraform versus 5 minutes from API/CLI/Web GUI.
This is a compounding problem as there are very few cases that use such as simple Load Balancer configuration. A more reasonable expectation would be 5 listener (e.g. Port 443) and 5 pools (each with 2 pool server members), which would take approximately 80 minutes. The API/CLI/Web GUI would remain at 5 minutes.
I can appreciate how the modular-only approach would be considered the correct approach, it is logical for Terraform purposes and there is no nested pools/members and listeners on the update[PATCH] API Endpoint.
A compromise needs to be found as this is far too long for execution of a Load Balancer setup. This may mean ibm_is_lb logic needs to be expanded to mask complexity and handle multiple API calls:
IF Load Balancer does not exist, execute create as currently + call API with pools and listeners
IF Load Balancer exists
remove pools and listeners input and confirm no update to make to the Resource, as currently
for each item in pools, call existing logic in ibm_is_lb_pool Terraform Resource
for each item in pools.members, call existing logic in ibm_is_lb_pool_member Terraform Resource
for each item in listeners, call existing logic in ibm_is_lb_listener
Community Note
Terraform CLI and Terraform IBM Provider Version
N/A
Affected Resource(s)
ibm_is_lb
Terraform Configuration Files
Expected Behavior
Terraform Resource
ibm_is_lb
should follow API Specification and uponcreate
allow data input via nested:Citation:
Actual Behavior
Terraform Resources are modular-only, there is no allowance for nested creation.
This means every end-user must use in sequence:
ibm_is_lb
(5-10 minutes provision time)ibm_is_lb_pool
(~4 minutes provision time, as a new pool will cause update/scan of the LB instance)ibm_is_lb_pool_member
for HA Pair Node A (~4 minutes provision time, as a new pool will cause LB update/scan )ibm_is_lb_pool_member
for HA Pair Node B (~4 minutes provision time, as a new pool will cause LB update/scan)ibm_is_lb_listener
(~4 minutes provision time, as a new pool will cause update/scan of the LB instance)Therefore, creating just 1 listener (e.g. Port 443) and 1 pool (with 2 pool server members) will take approximately 5 + 16 minutes using Terraform versus 5 minutes from API/CLI/Web GUI.
This is a compounding problem as there are very few cases that use such as simple Load Balancer configuration. A more reasonable expectation would be 5 listener (e.g. Port 443) and 5 pools (each with 2 pool server members), which would take approximately 80 minutes. The API/CLI/Web GUI would remain at 5 minutes.
I can appreciate how the modular-only approach would be considered the correct approach, it is logical for Terraform purposes and there is no nested pools/members and listeners on the
update
[PATCH] API Endpoint.A compromise needs to be found as this is far too long for execution of a Load Balancer setup. This may mean
ibm_is_lb
logic needs to be expanded to mask complexity and handle multiple API calls:create
as currently + call API withpools
andlisteners
pools
andlisteners
input and confirm no update to make to the Resource, as currentlypools
, call existing logic inibm_is_lb_pool
Terraform Resourcepools.members
, call existing logic inibm_is_lb_pool_member
Terraform Resourcelisteners
, call existing logic inibm_is_lb_listener