You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using a completely wrong firewall_id will create the resource with the wrong firewall id
resource"civo_instance""foo" {
hostname="amazingthingy20"tags=["python", "nginx"]
notes="This is a test-issue"size="g3.xsmall"region="LON1"firewall_id="fdsgdrefdfshgfdghdfsgsdref"# this field is wrongdisk_image="debian-11"
}
When listing the resource on the CLI we see this:
When going into the Dashboard we it's naming the firewall default:
But there is not firewall named Default:
This issue looks like it comes from the API, however when we create the same resource with the CLI, we don't get such issue:
Acceptance Criteria
Have this resource fail straight away when entering the wrong value fore firewall_id and return the error message from the API.
If the issue needs to be fixed on the API, fix it there, create internal tickets and/or liaise with anyone accordingly.
This ticket should be used as a reference for a bigger piece of work revamping the way we handle errors in terraform. The default behaviour with our provider seems to be to keep trying and it does NOT return the error the API gives, which is a problem.
We need to go through the entire provider and change the behaviour for everything not by writing error messages in terraform provider, but returning errors from the API
The text was updated successfully, but these errors were encountered:
fernando-villalba
changed the title
[BUG] No validation of firewall_id on civo_instance resource
[BUG] No validation of firewall_id on civo_instance resource on API?
Jul 22, 2024
Issues
Using a completely wrong
firewall_id
will create the resource with the wrong firewall idWhen listing the resource on the CLI we see this:
When going into the Dashboard we it's naming the firewall default:
But there is not firewall named Default:
This issue looks like it comes from the API, however when we create the same resource with the CLI, we don't get such issue:
Acceptance Criteria
This ticket should be used as a reference for a bigger piece of work revamping the way we handle errors in terraform. The default behaviour with our provider seems to be to keep trying and it does NOT return the error the API gives, which is a problem.
We need to go through the entire provider and change the behaviour for everything not by writing error messages in terraform provider, but returning errors from the API
The text was updated successfully, but these errors were encountered: