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

Support composable templates #1054

Closed
gingerwizard opened this issue Sep 1, 2020 · 4 comments
Closed

Support composable templates #1054

gingerwizard opened this issue Sep 1, 2020 · 4 comments
Assignees
Labels
enhancement Improves the status quo

Comments

@gingerwizard
Copy link

gingerwizard commented Sep 1, 2020

7.8 introduced composable and component templates. The unique api endpoints mean this is work.

We may want to separate these into different operations given the unique endpoints. A user would therefore index a set of component templates, followed by their composable templates.

Alternatively, we could extend the current create-template action to accept a mode where it first inserts the declared component_templates and then composable_templates that have been declared in the track. This would be a non breaking change as the mode would default to legacy which would cause the current behaviour.

@dliappis @danielmitterdorfer happy to take but please advise

@gingerwizard gingerwizard self-assigned this Sep 14, 2020
@gingerwizard gingerwizard added the enhancement Improves the status quo label Sep 14, 2020
@danielmitterdorfer
Copy link
Member

Thanks for raising this. I tend to the first option of dedicated runner(s) as I don't think Rally should abstract the Elasticsearch APIs much.

@dliappis
Copy link
Contributor

Also 👍 on dedicated runners; these should be first class citizens in Rally.

@gingerwizard
Copy link
Author

@danielmitterdorfer @dliappis the current template implementation uses the deprecated API. I'm not sure if the intention is to remove this in 8.0. For now, i propose we make these additions.

Do we want these to be first class definitions in the track? i.e. component_templates and index_templates (composable). The former need to be inserted before the latter i believe so a runner could consume both definitions and ensure this occurs.

Alternatively, we could require a single definition e.g. index_templates under which the user defines both composable and component templates. The runner could then either inspect the body to determine the appropriate API or use a type field defined in the track definition for each template e.g.

"index_templates": [
    {
        "name": "my-default-index-template",
        "index-pattern": "my-index-*",
        "template": "default-template.json",
        "type": "component"
    }
]

The benefit of declaring these as first class citizens is that we can use the definitions in other runners should we need them e.g. for validation.

@gingerwizard
Copy link
Author

Closed by #1099

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improves the status quo
Projects
None yet
Development

No branches or pull requests

3 participants