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

[Meta] Planned changes to the manifest format #517

Closed
26 of 29 tasks
ruflin opened this issue Jun 17, 2020 · 3 comments
Closed
26 of 29 tasks

[Meta] Planned changes to the manifest format #517

ruflin opened this issue Jun 17, 2020 · 3 comments
Assignees

Comments

@ruflin
Copy link
Contributor

ruflin commented Jun 17, 2020

A few changes are planned to the manifest(s) format. This is to track these changes:

Rename datasources to config_templates

We remove the term datasources across the different components. This now also has to be removed in the packages and be renamed to config_templates:

Cleanup terms

Cleanup terms used inside the registry.

Requirements to constraints

We currently use requirements section. To align with the agent and other parts, it should be renamed to constraints. In line with this task, also the default dependencies in the packages should be udpated.

Update categories

Directory names cleanup

Some of the directory names contained -, others _. This also had an effect on how the config options are called and what paths users have to define. To only have one way, it was decided to use _ everywhere and packages need to be adjusted.

Ingest pipeline config option

The ingest pipeline config option should be moved under the new Elasticsearch object for consistency

Rename input logs to logfile

More

More details to come

@ruflin ruflin self-assigned this Jun 17, 2020
@mtojek
Copy link
Contributor

mtojek commented Jun 18, 2020

Not sure if manifest files should change so much in time. I wonder what is the root cause of such evolving? Is it a matter of a discussion?

Also, what about existing packages (I'm asking specifically about Rename datasources to config_templates)?

@ruflin
Copy link
Contributor Author

ruflin commented Jun 18, 2020

The main reason for the changes are that we discussed quite a few naming changes over the last weeks in Agent / Kibana which I think should also make it into the packages to be consistent. And 7.9 is our last chance to really break things, so I rather do them all now. Happy to share more details related to each change.

For the datasources to config_templates I would expect us to "break" existing packages again. A general thought I have for 7.9 is that shortly before the release, we archive all the older versions of the packages we pushed so far as these will never be installed anyways.

@ruflin ruflin added the Ingest Management:beta1 Group issues for ingest management beta1 label Jun 29, 2020
ruflin added a commit to elastic/kibana that referenced this issue Jul 2, 2020
In elastic/package-registry#517 the naming of the file paths inside a package is standardised to only use `_` and not `-`. This adjusts the paths for `ilm-policy`, `component-template`, `index-template` to the correct path.

An additional change here is to get rid of assets we don't support yet, like rollup jobs and ml jobs. We will reintroduce these when we support them.
ruflin added a commit to ruflin/kibana that referenced this issue Jul 2, 2020
)

In elastic/package-registry#517 the naming of the file paths inside a package is standardised to only use `_` and not `-`. This adjusts the paths for `ilm-policy`, `component-template`, `index-template` to the correct path.

An additional change here is to get rid of assets we don't support yet, like rollup jobs and ml jobs. We will reintroduce these when we support them.
ruflin added a commit to elastic/kibana that referenced this issue Jul 2, 2020
…70600)

In elastic/package-registry#517 the naming of the file paths inside a package is standardised to only use `_` and not `-`. This adjusts the paths for `ilm-policy`, `component-template`, `index-template` to the correct path.

An additional change here is to get rid of assets we don't support yet, like rollup jobs and ml jobs. We will reintroduce these when we support them.
@ruflin ruflin assigned ph Jul 3, 2020
ph added a commit to ph/beats that referenced this issue Jul 9, 2020
ph added a commit to elastic/beats that referenced this issue Jul 13, 2020
…19761)

* [Elastic Agent] Remove support for "logs" and only support logfile

We want to move away from logs to `logfile`

Reference: elastic/package-registry#517

* Changelog
ph added a commit to ph/beats that referenced this issue Jul 13, 2020
…lastic#19761)

* [Elastic Agent] Remove support for "logs" and only support logfile

We want to move away from logs to `logfile`

Reference: elastic/package-registry#517

* Changelog

(cherry picked from commit 2682ec8)
ph added a commit to elastic/beats that referenced this issue Jul 13, 2020
…19761) (#19850)

* [Elastic Agent] Remove support for "logs" and only support logfile

We want to move away from logs to `logfile`

Reference: elastic/package-registry#517

(cherry picked from commit 2682ec8)
@ruflin ruflin unassigned ph Aug 10, 2020
@ruflin ruflin added Ingest Management: beta2 and removed Ingest Management:beta1 Group issues for ingest management beta1 labels Aug 18, 2020
melchiormoulin pushed a commit to melchiormoulin/beats that referenced this issue Oct 14, 2020
…lastic#19761)

* [Elastic Agent] Remove support for "logs" and only support logfile

We want to move away from logs to `logfile`

Reference: elastic/package-registry#517

* Changelog
@ruflin
Copy link
Contributor Author

ruflin commented Nov 3, 2020

@ycombinator @ph @mtojek I'm going to close this issue as moving forward, we can't do any breaking changes anymore to the package.

@ruflin ruflin closed this as completed Nov 3, 2020
jsoriano pushed a commit to elastic/package-spec that referenced this issue Feb 1, 2022
It is already assumed that packages shouldn't contain
directories with hyphens in their names. EPR is already
rejecting them since elastic/package-registry#517.

Add this restriction to the spec.
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

No branches or pull requests

3 participants