Question

大多数地形提供者都需要预定义的流程，即创建/读取/更新/删除/存在

我处于一种怪异的境地，开发了针对API的提供程序，这种行为会有所不同。

有两种资源，主机和范围。主机可以具有多个作用域。作用域将通过配置进行更新。

这通常很适合地形流，它可能具有完整的CRUDE流-除了一个实例之外。

创建新主机后，它会自动附加一个默认范围。它始终存在，无法删除等。

我不知道如何让我的提供者妥善处理此问题，因为我希望tf像对待其他任何资源一样对待它，但是它没有明确的CREATE / DELETE，只有READ / UPDATE / EXISTS -但附加到主机的所有其他范围都将创建/删除。

由于密度高，导入不是一种选择，要求每台主机导入都会使整个事情变得毫无意义。

我本来打算将范围和配置拆分为单独的资源，以便主机可以完全填充（主机为配置提供范围ID，然后其他配置可以从范围中获取其范围ID资源）

但是，这种方法会失败，因为两者的API相同，除非我想添加创建空作用域的抽象，然后对其应用配置，但可能不完全支持该配置。本质上，将由两个资源控制一个资源，这可能导致剧烈的冲突。

我考虑过要执行的释义示例

resource "host" "test_integrations" {
    name = "test.integrations.domain.com"
    account_hash = "${local.integrationAccountHash}"
    services = [40]

}

resource "configuration" "test_integrations_root_configuration" {
    name = "root"
    parent_host = "${host.test_integrations.id}"
    account_hash = "${local.integrationAccountHash}"
    scope_id = "${host.test_integrations.root_scope_id}"
    hostnames = ["test.integrations.domain.com"]
}

resource "scope" "test_integrations_other" {
    account_hash = "${local.integrationAccountHash}"
    host_hash = "${host.test_integrations.id}"
    path = "/non/root/path"
    name = "Some Other URI Path"
}

resource "configuration" "test_integrations_other_configuration" {
    name = "other"
    parent_host = "${host.test_integrations.id}"
    account_hash = "${local.integrationAccountHash}"
    scope_id = "${host.test_integrations_other.id}"
}

在此示例流程中，不幸的是，配置和作用域资源指向的是同一资源，我担心这将导致谁负责什么的冲突或混乱，并极大地混淆了创建/删除生命周期

但是我无法弄清楚TF生命周期如何允许一种资源，如果给出了一个标志，该资源仅会更新/读取/存在（以及状态如何处理）

另一种选择是仅拥有配置资源，但是如果它是根配置，则由于它与主机固有地绑定，因此需要跳过创建/删除

理想情况下，我可以很好地处理这种情况。我试图避免在主机定义中包含根作用域/配置，因为这会在写入和处理方式上造成分歧。

提供程序的文档暗示您可以在资源中以架构对象的形式使用资源，但没有说明如何或为什么。如果它按照我的想象进行工作，则可能会创建一个可能仅用于注入主机的资源-但我不知道这是否是它的工作方式，以及它是如何实现的。

Answer 1

我相信在问了一些有关地鼠松弛的人后，我已经找到了解决方法。

使用AWS Provider Default VPC作为参考，我可以使用自定义的“创建/删除”生命周期将资源“克隆”为一个资源。

宽松示例：

func defaultResourceConfiguration() *schema.Resource {
    drc := resourceConfiguration()
    drc.Create = resourceDefaultConfigurationCreate
    drc.Delete = resourceDefaultConfigurationDelete

    return drc
}

func resourceDefaultConfigurationCreate(d *schema.ResourceData, m interface{}) error {
    // double check it exists and update the resource instead
    return resourceConfigurationUpdate(d, m)
}

func resourceDefaultConfigurationDelete(d *schema.ResourceData, m interface{}) error {
    log.Printf("[WARN] Cannot destroy Default Scope Configuration. Terraform will remove this resource from the state file, however resources may remain.")
    return nil
}

这应该允许我提供一个相同的资源，该资源旨在与其父主机创建的资源进行交互。

如何在自定义terraform提供程序中使用隐式创建步骤处理怪异的API流

1 个答案: