infobloxopen / terraform-provider-bloxone

terraform-provider-bloxone
Apache License 2.0
5 stars 10 forks source link

Bug bloc data dns view #138

Open SamirT-hub opened 4 months ago

SamirT-hub commented 4 months ago

Hello,

Hope you are going well. We have used the bloc data to have the characteristics of the dns view. and align our pipeline terraform so we take back the exact same configuration.

FYI, the DNS sec was disable in the global properties + EDNS enable for certain domain. The views are in inherited mode from global properties.

But what is strange is that we observed in the stated of all the views, normally in the state we should nothing: dnssec_root_keys = [

But what is stranger is when we force push in the view we have which is normal as we have not dns sec configured in dns global properties or aaa acl: ╷ │ Error: Provider produced inconsistent result after apply │ │ When applying changes to module.iac--bloxone-dns-view["ari-test-iac"].bloxone_dns_view.bloxone_dns_view, provider │ "provider[\"registry.terraform.io/infobloxopen/bloxone\"]" produced an unexpected new value: .filter_aaaa_acl: was null, but now │ cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{"access":cty.StringVal("allow"), "acl":cty.NullVal(cty.String), │ "address":cty.StringVal(""), "element":cty.StringVal("any"), │ "tsig_key":cty.NullVal(cty.Object(map[string]cty.Type{"algorithm":cty.String, "comment":cty.String, "key":cty.String, │ "name":cty.String, "protocol_name":cty.String, "secret":cty.String}))})}). │ │ This is a bug in the provider, which should be reported in the provider's own issue tracker.

SamirT-hub commented 4 months ago

a precision I talked about data bloc but we just use the data bloc for the terraform import of the view. Once we have imported the view and aligned the configuration we saw this difference: dnssec_root_keys = [

Which was not even in the configuration of csp.eu.infoblox.com

mathewab commented 4 months ago

Hi @SamirT-hub, Thank you for reporting the issue. Could you please provide a sample config that caused this error for you?

SamirT-hub commented 4 months ago

Hi, of course no issue: so here is my deployment code very easy: module "iac--bloxone-dns-view" { source = "github.com/auchan-retail-international/iac--bloxone-dns-view" for_each = var.viewname name = each.key address = each.value.address }

viewname = { "ari-view-az-001" = { address = "10.192.48.0/28" }, "ari-view-az-np-001" = { address = "10.193.50.96/28" }, "ari-view-ovh-001" = { address = "10.195.0.0/16" }, "ari-view-ovhdpw-001" = { address = "10.113.0.96/28" }, "ari-view-oci-001" = { address = "10.199.66.0/24" }, "ari-view-gcp-001" = { address = "10.199.76.8/29" }, "ari-view-gcp-np-001" = { address = "10.199.84.8/29" }, "ari-view-sites-001" = { address = "10.86.0.0/16" } }

My module: resource "bloxone_dns_view" "bloxone_dns_view" { name = var.name match_clients_acl = [ { access = "allow" element = "any" } ] match_destinations_acl = [ { access = "allow" element = "ip" address = var.address } ] } So as you can see I am not managing the dns sec public key or aaa acl.

I have done import of all the views here is one example: terraform import -var-file=env/prd.tfvars 'module.iac--bloxone-dns-view["ari-view-az-001"].bloxone_dns_view.bloxone_dns_view' dns/view/8b74b64c-e513-4ff0-b5bf-b1148f2df148

When I look at the state what is strange si that all my 9 views have public key dns sec and aaa acl configured whereas I configured via dns properties uncheck dns sec and aaa acl is configured by default to any.

As I am not managing this part in the dns view terraform and it is inherited I never mentionned it in my code + state imported is false as we have unchecked DNS sec. What is more strange is that the action of modify is done only in 3 of my 9 zones here is a plan of the changes: resource "bloxone_dns_view" "bloxone_dns_view" { ~ created_at = "2024-03-12T19:18:12Z" -> (known after apply) ~ dnssec_root_keys = [

SamirT-hub commented 3 months ago

Hi mathewab,

Do you need anything else ? Thank you.

Samir TENNAH.

mathewab commented 3 months ago

Hi Samir,

Thank you for sharing the config. As I understand, the issue that you are facing is during the "terraform import". The state has additional values in the config that you didn't expect.

The extra values that you see in the state might already be in the object in the API. In the UI, you might not be seeing it since the "override" toggle hides it. If you turn on the toggle, you might be able to see the values in the UI as well. Since they are not overridden, the applied config will not have these values, but are still present in the object.

The dnssec_root_keys are default values that shouldn't affect when you do terraform plan since the same default is also configured in the terraform provider. However for filter_aaaa_acl the terraform provider has no default value, so it is complaining in the plan. There is no default value in the API as well, and I observed that the UI sends the "allow/any" value as the default whenever the view is saved in the UI. I will need to confirm with the team if this is the intended default value or not.

A workaround to this would be to explicitly set filter_aaaa_acl as below and run terraform plan. As mentioned earlier, this wouldn't have an effect on the applied config, as the override action is set to "inherit"

   filter_aaaa_acl = [
    {
      access  = "allow"
      element = "any"
    }
  ]
SamirT-hub commented 3 months ago

Hi Ashish,

Here the issue is that the import is done exactly in the same ways for all views and in the state for all the views we have exactly the same thing, here an example: publickey

But when I push my code without indicating aaaa_acl and dns sec I only have error for 3 out of 9 views. I don't understand this different behaviour. If I refer to the state file, we have the exact same state for all the views. I should either see modifications in the 9 views of dns sec aaaa_acl or either nothing on the 9 views.

Moreover, this is strange to manage this specifity only for the 3 views and indicate nothing for the other views this complicates my code. If you want a small demo of the issue I can show you very easily.

Samir TENNAH.

mathewab commented 3 months ago

Hi Samir,

There is an issue with the UI that adds these values to filter_aaaa_acl when you edit the view (even without any changes made to the view). This behaviour is not seen when the view is first created. As a result, it may be that only three of the views were updated with these values in the UI.

Since there are only 3 views that have these problem, I understand that you don't want to add this config for all views since you use a module for it. I understand that you tried to apply the plan without the config change and it didn't work. That is because of an issue with the provider where setting null values for list doesn't unset the list. Having filter_aaaa_acl = [] does unset the value in the backend, but the provider still gives an error about inconsistent plan. We will work on this issue and try to provide a fix for it.

In the meantime, for unsetting, you can do a workaround that involves 2 steps.

  1. Add this line to your view filter_aaaa_acl = [] and run terraform apply. This will give an inconsistent plan error.
  2. Remove the above line and run terrafrom apply again. This time it shouldn't give any error.
SamirT-hub commented 3 months ago

Hi =,

Unfortunately still the same :/ ╷ │ Error: Provider produced inconsistent result after apply │ │ When applying changes to module.iac--bloxone-dns-view["fake"].bloxone_dns_view.bloxone_dns_view, provider │ "provider[\"registry.terraform.io/infobloxopen/bloxone\"]" produced an unexpected new value: .filter_aaaa_acl: was null, but now │ cty.ListVal([]cty.Value{cty.ObjectVal(map[string]cty.Value{"access":cty.StringVal("allow"), "acl":cty.NullVal(cty.String), │ "address":cty.StringVal(""), "element":cty.StringVal("any"), │ "tsig_key":cty.NullVal(cty.Object(map[string]cty.Type{"algorithm":cty.String, "comment":cty.String, "key":cty.String, │ "name":cty.String, "protocol_name":cty.String, "secret":cty.String}))})}). │ │ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Samir TENNAH.

SamirT-hub commented 2 months ago

Hello,

Any news ? Thank you.

Samir TENNAH.