[SCHEMA]: "elasticstack_data_*" resources

[tsouza]

The elasticstack_data_* defines the following:

Index Template

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-put-template.html

resource 'elasticstack_data_index_template' '<name>' {
    index_patterns  []string
    priority        integer
    version         integer
    metadata {
        # variable key/value pair
    }
    composed_of     []string
    data_stream {
        hidden       boolean
    }
    template {
        settings {
            # variable key/value pair - Should we force the usage of flat settings?
        }
        aliases {
            # key/value pair "alias_name" -> "alias_def" see https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-aliases.html 
        }
        mappings {
            # see https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-put-mapping.html
        }
    }
}

Component Template

https://www.elastic.co/guide/en/elasticsearch/reference/current/indices-put-template.html#multiple-component-templates

resource 'elasticstack_data_component_template' '<name>' {
    # defines only "template" field from Index Template
}

Index Lifecycle Policy

https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-put-lifecycle.html

resource 'elasticstack_data_index_lifecycle_policy' '<name>' {
    hot_phase {
        keep_data_forever boolean
        set_read_only     boolean
        index_priority  integer
        force_merge {
            number_of_segments  integer
        }
        shrink {
            number_of_primary_shards    integer
        }
        rollover {
            max_index_size  string
            max_documents   integer
            max_age         string
        }
        searchable_snapshot {
            repository_name     string
        }
    }
    warm_phase {
        move_data_into_phase_when   string
        keep_data_forever boolean
        set_read_only     boolean
        index_priority    integer
        replicas {
            number_of_replicas  integer
        }
        force_merge {
            number_of_segments  integer
        }
        shrink {
            number_of_primary_shards    integer
        }
        data_allocation {
            custom {
                # variable key/value pair
            }
        }
    }
    cold_phase {
        move_data_into_phase_when   string
        keep_data_forever boolean
        set_read_only     boolean
        index_priority    integer
        freeze_index      boolean
        replicas {
            number_of_replicas  integer
        }
        force_merge {
            number_of_segments  integer
        }
        data_allocation {
            custom {
                # variable key/value pair
            }
        }
        searchable_snapshot {
            repository_name     string
        }
    }
}

Snapshot Repository

https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html

resource 'elasticstack_data_snapshot_repository' '<name>' {
    type    string
    settings {
        # variable key/value pair
    }
}

[tsouza]

Notes:

• Data Stream: after putting more thoughts on it, I realized that there is no value added in defining a Data Stream resource as a data stream will be created when data is indexed anyway (the Kibana UI itself does not allows creating the Data Stream in advance). The resource would only enable a kill-switch to delete all data in case the resource is delete, which I believe is not really useful. We should leave the data_stream setting in the index template as is which enables it to be able to create new data streams.
• lifecycle_policy setting in Index Template - Indeed would be handy to have that defined as a shortcut for the actual setting, but then why not do the same for the other settings (such as the default ingest pipeline?). I agree which should put more thought on how to improve the resources definition under the UX perspective but I think we should properly revisit this topic in a future version. For now, let's just try to stick with what's there already without introducing new concepts/models. See https://github.com/stevewritescode/terraform-provider-elastic-stack/issues/6