Describe the bug I want to play around with the provider and I am testing and can't get it to work. Get an Provider produced inconsistent result after apply error (see below). Testing on RouterOS 7.4. Is this a bug or do I do something wrong?

To Reproduce I created a simple file: terraform { required_providers { routeros = { source = "GNewbury1/routeros" } } }

provider "routeros" { hosturl = "https://10.252.10.1" username = "abc" password = "appeltaart" insecure = true }

resource "routeros_ip_pool" "pool" { name = "my_ip_pool" ranges = "10.0.0.100-10.0.0.200" }

Expected behavior It works..

Stack Trace If applicable, add the stack trace the crash produced.

Additional context Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:

• create

Terraform will perform the following actions:

routeros_ip_pool.pool will be created

• resource "routeros_ip_pool" "pool" {
  • id = (known after apply)
  • name = "my_ip_pool"
  • ranges = "10.0.0.100-10.0.0.200" }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions? Terraform will perform the actions described above. Only 'yes' will be accepted to approve.

Enter a value: yes

routeros_ip_pool.pool: Creating... ╷ │ Error: Provider produced inconsistent result after apply │ │ When applying changes to routeros_ip_pool.pool, provider "provider["registry.terraform.io/gnewbury1/routeros"]" │ produced an unexpected new value: Root resource was present, but now absent. │ │ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Describe the bug I setup a RouterOS with two addresses (*1 and *2, using 10.0.9.1/24 and 192.168.88.1/24), the REST api also returns the correct values.

Using the terraform provider, the list contains the same address twice and is missing the first one. When I create a third address, the array contains three times the last one.

This is also reproducable for the interfaces and routes datasource.

ip_addresses = {
  "addresses" = tolist([
    {
      "actual_interface" = "ether1"
      "address" = "192.168.88.1/24"
      "disabled" = true
      "dynamic" = false
      "id" = "*2"
      "interface" = "ether1"
      "invalid" = false
      "network" = "192.168.88.0"
    },
    {
      "actual_interface" = "ether1"
      "address" = "192.168.88.1/24"
      "disabled" = true
      "dynamic" = false
      "id" = "*2"
      "interface" = "ether1"
      "invalid" = false
      "network" = "192.168.88.0"
    },
  ])
  "id" = "terraform-20220120102446891700000001"
}

To Reproduce Setup multiple routes, addresses or interfaces and query those.

Minimal terraform example:

provider "routeros" {
  hosturl  = "https://10.0.9.150"
  username = "admin"
  password = ""
  insecure = true
}

data "routeros_interfaces" "interfaces" {}

data "routeros_ip_routes" "routes" {}

data "routeros_ip_addresses" "addresses" {}


output "interfaces" {
  value = data.routeros_interfaces.interfaces
}

output "ip_addresses" {
  value = data.routeros_ip_addresses.addresses
}

output "routes" {
  value = data.routeros_ip_routes.routes
}

Expected behavior Array with the correct entries.

Because we cannot 'delete' a System Identity we just reset it back to the default MikroTik. If that's not the best idea, we can instead just make the delete a 'no op' and skip it.

Closes #55

This seemed to work well during minimal testing, it could use a thorough review though.

I also couldn't get the doc generation to work, so you may need to add those.

Describe the bug Not an expert for RouterOS but when I want to create a bridge interface without setting the pvid parameter, I'm getting following error:

When applying changes to routeros_interface_bridge.bridge, provider "provider[\"registry.terraform.io/gnewbury1/routeros\"]" produced an unexpected new value: Root resource was present, but now absent.

After looking into Terraform debug logs I noticed following line:

{"@level":"warn","@message":"unexpected data","@timestamp":"2022-10-23T14:04:28.141949+02:00","registry.terraform.io/gnewbury1/routeros:stdout":"value of pvid out of range (1..4094)"}

Based on the error and according to the [docs[(https://help.mikrotik.com/docs/display/ROS/Bridging+and+Switching) I'm assuming that default value should be 1 and not 0 as in the current state:

"pvid": {
    Type:     schema.TypeInt,
    Optional: true,
    Default:  0,
},

To Reproduce Try to apply example configuration of routeros_interface_bridge

Expected behavior Successful creation of bridge interface

Stack Trace

routeros_interface_bridge.bridge: Modifying... [id=*<id>]
....
{"@level":"trace","@message":"received data","@module":"provider.stdio","@timestamp":"2022-10-23T14:04:28.141913+02:00","channel":"STDOUT","len":36}
{"@level":"warn","@message":"unexpected data","@timestamp":"2022-10-23T14:04:28.141949+02:00","registry.terraform.io/gnewbury1/routeros:stdout":"value of pvid out of range (1..4094)"}
....
│ Error: Provider produced inconsistent result after apply
│
│ When applying changes to routeros_interface_bridge.bridge, provider "provider[\"registry.terraform.io/gnewbury1/routeros\"]" produced an unexpected new value: Root resource was present, but now absent.
│
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Additional context Versions: Terraform: 1.3.3 Provider: 0.3.4 RouterOS: 7.5

My code:

#tfvars file content: identity = "mt-crs112"

variable "identity" {
  type = string
}

resource "routeros_system_identity" "ros_identity" {
    name = var.identity
}

Output of terraform apply:

routeros_system_identity.ros_identity: Refreshing state... [id=mt-oldname]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # routeros_system_identity.ros_identity will be updated in-place
  ~ resource "routeros_system_identity" "ros_identity" {
        id   = "mt-oldname"
      ~ name = "mt-oldname" -> "mt-crs112"
    }

Plan: 0 to add, 1 to change, 0 to destroy.
routeros_system_identity.ros_identity: Modifying... [id=mt-oldname]
routeros_system_identity.ros_identity: Modifications complete after 1s [id=mt-oldname]

After apply the name is still "mt-oldname".

Mikrotik model: CRS112 RouterOS: 7.6 (same result with 7.4) Terraform: v1.3.7 Provider: v0.4.0 Go: go1.19.4

It would be very cool to help add support for let's encrypt by combining with the acme provider, things needed for this:

Lifecycle of certificate Assign to services, api, www, ikev2

Describe the bug This happens when running terraform apply. I am also unable to make an ip address resource. It throws error no matter what I try. My below code was working for a bit then started giving this error after I kept trying to get the IP address resource to work.

To Reproduce

terraform {
  required_providers {
    routeros = {
      source = "GNewbury1/routeros"
    }
  }
}

provider "routeros" {
  hosturl  = "https://172.21.0.1"
  username = "username"
  password = "password"
  insecure = true
}


locals {
  network71 = {
    name = "vlan71-smartDevices"
    address = "10.71.0.0"
    gateway = "10.71.0.1"
    cidr = "/24"
    vlan = 71
  }
  domain   = "yoshi.lan"
}

resource "routeros_interface_vlan" "vlan-vlan71-smartDevices" {
  interface = "bridge-lan"
  name      = local.network71.name
  vlan_id   = local.network71.vlan
}
resource "routeros_ip_pool" "pool-vlan71-smartDevices" {
  name   = local.network71.name
  ranges = "10.0.71.100-10.0.71.200"
}
resource "routeros_ip_dhcp_server_network" "dhcpNetwork-vlan71-smartDevices" {
  address    = format("%s%s",local.network71.address,local.network71.cidr)
  gateway    = local.network71.gateway
  dns_server = local.network71.gateway
  domain     = local.domain
}
resource "routeros_ip_dhcp_server" "dhcpServer-vlan71-smartDevices" {
  address_pool = local.network71.name
  interface    = local.network71.name
  name         = local.network71.name
}

Output:

routeros_ip_dhcp_server.dhcpServer-vlan71-smartDevices: Creating...
routeros_interface_vlan.vlan-vlan71-smartDevices: Creating...
routeros_ip_pool.pool-vlan71-smartDevices: Creating...
routeros_ip_dhcp_server_network.dhcpNetwork-vlan71-smartDevices: Creating...
routeros_ip_dhcp_server_network.dhcpNetwork-vlan71-smartDevices: Creation complete after 0s [id=*18]
routeros_ip_pool.pool-vlan71-smartDevices: Creation complete after 0s [id=*1C]
routeros_interface_vlan.vlan-vlan71-smartDevices: Creation complete after 0s [id=*24]
╷
│ Error: Provider produced inconsistent result after apply
│ 
│ When applying changes to routeros_ip_dhcp_server.dhcpServer-vlan71-smartDevices, provider
│ "provider[\"registry.terraform.io/gnewbury1/routeros\"]" produced an unexpected new value: Root resource was
│ present, but now absent.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

Expected behavior Expected to run without error and create the dhcp server resource

Stack Trace If applicable, add the stack trace the crash produced.

Additional context Add any other context about the problem here.

Is your feature request related to a problem? Please describe. A container is MikroTik's implementation of Linux containers, allowing users to run containerized environments within RouterOS. For example run traefik would be very useful!

Describe the solution you'd like Manage lifecycle for containers, env variables, versions, etc.

Additional context Here oficial guide for create container https://help.mikrotik.com/docs/display/ROS/Container

Describe the bug In the code, the returned object (d.set) has a property (src_port) that is being filled by the returned object's "Port" attribute. This should be filled by the returned object's "SrcPort" attribute.

To Reproduce In the routeros/resource_ip_firewall_filter.go file, on line 475, the line reads: d.Set("src_port", res.Port).

Expected behavior In the routeros/resource_ip_firewall_filter.go file, on line 475, the line should read: d.Set("src_port", res.SrcPort).

Stack Trace No Stack Trace, does not crash, just returns incorrect data.

Additional context No additional context here.