Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for ES index-template configs #552

Merged
merged 3 commits into from
Jun 30, 2020
Merged

Conversation

ruflin
Copy link
Member

@ruflin ruflin commented Jun 24, 2020

In some cases, the Elasticsearch index template for a dataset needs more configuration options then just the mappings that can be shipped as the fields.yml. To make this possible, this introduces the option to configure some settings in the dataset manifest. The naming is elasticsearch.index-template to be in line with the directory names. Inside settings and mappings are supported as free form. Anything else is ignored.

This is not supported yet on the Kibana side. There this should either be put into a separate component template or merge on creation.

@ruflin
Copy link
Member Author

ruflin commented Jun 24, 2020

@skh @neptunian How would we implement this best on the Kibana side?

@elasticmachine
Copy link

elasticmachine commented Jun 24, 2020

💚 Build Succeeded

Pipeline View Test View Changes Artifacts preview

Expand to view the summary

Build stats

  • Build Cause: [Pull request #552 updated]

  • Start Time: 2020-06-30T20:12:58.018+0000

  • Duration: 9 min 54 sec

Test stats 🧪

Test Results
Failed 0
Passed 143
Skipped 0
Total 143

Title string `config:"title" json:"title" validate:"required"`
Release string `config:"release" json:"release"`
Type string `config:"type" json:"type" validate:"required"`
IngestPipeline string `config:"ingest_pipeline,omitempty" config:"ingest_pipeline" json:"ingest_pipeline,omitempty" yaml:"ingest_pipeline,omitempty"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now that we have an Elasticsearch field, should IngestPipeline be moved under it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. I would say yes!

Copy link
Contributor

@ycombinator ycombinator Jun 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will such a change pose a problem in terms of BWC for existing manifests?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes and no. After 7.9 we must stop doing these changes but until then we can still update old ones. The way I plan such changes are:

  • Update registry and support both format. Read in and output.
  • Update Kibana and packages / integrations scripts
  • Remove legacy code

@ycombinator Any help getting this changes in is appreciated ;-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I'm missing something about the plan but shouldn't there be an IngestPipeline field in the Elasticsearch struct below?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, the plan is to introduce it in #564.

util/dataset.go Outdated
@@ -84,6 +85,11 @@ type Os struct {
Windows interface{} `config:"windows" json:"windows,omitempty" yaml:"windows,omitempty"`
}

type Elasticsearch struct {
IndexTemplateSettings map[string]interface{} `config:"index-template.settings" json:"index-template.settings,omitempty" yaml:"index-template.settings,omitempty"`
Copy link
Contributor

@ycombinator ycombinator Jun 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: consistency. For ingest pipelines we use ingest_pipeline (underscore-delimited) but for index templates we use index-template (hyphen-delimited).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Glad you bring this up. I remember we had in the past a discussion that we should standardise. You have any preference?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tl;dr: I lean towards underscore.

When it comes to defining these fields in JSON or YAML I don't think it matters much, especially since we would never start a field name with a delimiter (otherwise hyphens could be problematic in YAML).

When it comes to deserializing these fields into language constructs, hyphen could be problematic in some languages as it might represent subtraction.

So I lean towards underscore.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's clean it up and go with underscore!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I filed #565 for this and will clean up the PR.

ruflin added a commit to ruflin/package-registry that referenced this pull request Jun 29, 2020
In elastic#552 `elasticsearch` as config block is introduced. As discussed there, it also makes sense to use this for the Ingest Pipeline config to have all Elasticsearch related parts in one place.

For now no package uses this change and Kibana does not support it. As both ways are supported, this is not a breaking change yet. As a follow up, the package generation must be updated to adjust for this option and Kibana must be adapted to only support the new option.
@ruflin ruflin requested a review from ycombinator June 29, 2020 07:01
@ruflin
Copy link
Member Author

ruflin commented Jun 29, 2020

@ycombinator PR updated, would be great if you could have a look again.

index_template.mappings:
dynamic: false
index_template.settings:
index.lifecycle.name: reference
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: you could break out the index_template key into it's own level and nest mappings and settings under it, like you did in testdata/package/yamlpipeline/1.0.0/dataset/log/manifest.yml.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually didn't do it on purpose to make sure I test that both options work.

@ycombinator
Copy link
Contributor

Left a nitpick. PR needs rebase due to conflicts.

Copy link
Contributor

@jonathan-buttner jonathan-buttner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should work for endpoint. Thanks for implementing it!

In some cases, the Elasticsearch index template for a dataset needs more configuration options then just the mappings that can be shipped as the fields.yml. To make this possible, this introduces the option to configure some settings in the dataset manifest. The naming is `elasticsearch.index-template` to be in line with the directory names. Inside settings and mappings are supported as free form. Anything else is ignored.

This is not supported yet on the Kibana side. There this should either be put into a separate component template or merge on creation.
Copy link
Contributor

@ycombinator ycombinator left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@ruflin ruflin merged commit 71f9dff into elastic:master Jun 30, 2020
@ruflin ruflin deleted the es-configs branch June 30, 2020 20:26
ruflin added a commit to ruflin/package-registry that referenced this pull request Jul 1, 2020
In elastic#552 `elasticsearch` as config block is introduced. As discussed there, it also makes sense to use this for the Ingest Pipeline config to have all Elasticsearch related parts in one place.

For now no package uses this change and Kibana does not support it. As both ways are supported, this is not a breaking change yet. As a follow up, the package generation must be updated to adjust for this option and Kibana must be adapted to only support the new option.
ruflin added a commit that referenced this pull request Jul 2, 2020
In #552 `elasticsearch` as config block is introduced. As discussed there, it also makes sense to use this for the Ingest Pipeline config to have all Elasticsearch related parts in one place.

For now no package uses this change and Kibana does not support it. As both ways are supported, this is not a breaking change yet. As a follow up, the package generation must be updated to adjust for this option and Kibana must be adapted to only support the new option.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants