[Request] more resources

[thomasfinstad]

I was wondering if you plan on adding more resources and improve / create a doc? I am looking for the best way to manage vyos config and this is currently the only terraform provider

[foltik]

I initially started this project precisely since there were no other vyos providers available, which is why it's so minimal right now.

I'm unfortunately pretty busy with other things currently, so I'm only adding extra features to this and the go client as I come across the need for them in my own scripts.

Any contributions are more than welcome.

[thomasfinstad]

Thanks for the reply, I might try to use this against my own rolling vyos 1.4 and maybe I can learn to contribute back at some point.

I have zero experience with go so if you know of a good "zero to beginner" guide I would be glad to read it.

I suppose you can just close this issue unless you want to keep it open for others to see.

[thomasfinstad]

I am looking to add some more resources, but I have a situation where I am not able to make up my mind, so I am asking you @Foltik for your opinion so that the provider can have as uniform a feel as possible.

Should the resources require parent resources be for allowing themself to be created, or do we not wish the small drift away from how VyOS works?

Pros:

• It will make sure you are doing things in the proper order
• Your settings will be more visible as they will have terraform defaults applied instead of hidden VyOS defaults with no feedback.
• If you later add the config for a parent it would have to be imported as the key already exist if we do not require it.

Cons:

• We have to code in the check for each resource that has a logical parent
• We are adopting an extra requirement on how you can configure the system

I am leaning more towards adding in the requirement, I think the fact that you would have to import the parent resource if you did not add it first is an ugly user experience, and I am also worried it might break during apply if a child is applied before the parent, meaning you would have to import even though you configured it ahead of time.

As an example think of firewall rule-set as the parent, and a firewall rule as the child.

If you just configure a rule VyOS will allow it, this will obviously also create the keypath for the rule-set. This means if you in terraform create the rule, then later add a resource for the rule-set you will have to import the rule-set since the key already exists. This seems messy to me and I think it would be better to have a check that makes sure you have the logical parent configured first, but I might be overthinking it.

[foltik]

I'm leaning towards adding in the requirement as well. While it might be convenient to configure just a few things on an existing system, I think one of the main reasons for using Terraform like this in the first place is to be able to re-provision everything from scratch. I think the goal should be to have the Terraform resources fully capture any other state that they depend on.

Here's a couple ideas to that effect:

Auto import and update when creating resources

When creating ex. a firewall rule-set resource with a specific name, we could first check if it exists. If it does, we overwrite all of its attributes with the user specified ones (which we know from the schema).

This should make it easier to migrate from raw config resources to typed resources.

Require parent IDs in child schema

Instead of adding API calls to check that parents exist when creating children, we could follow the implicit dependencies route and instead require a reference to the parent resource in the child's schema. This way Terraform's planning step would handle the ordering for us. For example:

resource "vyos_firewall" "my_firewall" {
    # ...
}

resource "vyos_firewall_rule" "my_rule" {
    firewall = vyos_firewall.my_firewall.id
    # ...
}

Full config import

We could provide some way to import everything from an existing config.

It doesn't seem like terraform import can do this in a way that creates multiple resources, but it could still be useful to create a giant config_block with your existing configuration that could be migrated away from incrementally.

[thomasfinstad]

Thanks for the input! I think we are pretty much on the same page, though I think that in addition to requiring the parent ID we should also check that the parent is really there with an API call to keep terraform from "magically" creating a skeleton resource that is not in code.

[angelnu]

@Foltik , @thomasfinstad : there are also cases where the child has to be created in the same commit as the parent - see example in #6

What would we prefer?

• allowing config_block to handle children (keys with spaces)
• create a new resource (config_block_tree)

In think having a new resource would be cleaner since then we can differentiate the case where the whole tree is managed by the terraform resource vs the case where we only want to manage the parent and not the children.

Btw: I would prototype on top of @thomasfinstad ´s fork as his helpers make it easier to add the new resource.

[jtcarnes]

I'd love to contribute. I have experience with writing terraform plugins. Do we have a wish list of resources?

[angelnu]

@jtcarnes - basically each chapter at https://docs.vyos.io/en/equuleus/configuration/index.html could be modeled in Terraform with its own Terraform. Currently only static host mappings are implemented as individual resource.

Please notice that since Terraform does not support (yet) batching of request and the Vyos API is not the fastest. Supporting multiple objects (such as static DHCP entries) would be more efficient to avoid too many API calls.

[foltik]

@jtcarnes I think the most useful resources to add at this point would be ones which are configured often, such as firewall rules, NAT rules, static DHCP mappings, etc.

Expanding upon what @angelnu said re batching: From the discussion in https://github.com/hashicorp/terraform-plugin-sdk/issues/66 it looks like the currently recommended approach is to have separate "batch" variants of resources to work around Terraform not supporting any kind of batching of multiple separate resources.