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

Do not load ML jobs to 8.x from 7.x releases #27771

Merged
merged 7 commits into from
Oct 6, 2021

Conversation

kvch
Copy link
Contributor

@kvch kvch commented Sep 7, 2021

What does this PR do?

This PR adds a check before loading ML assets to make sure, Beats are loading those to ES 7.x. If someone tries to load ML into ES 8.x, they are told to use the Machine Learning UI in Kibana.

This PR is opened against 7.x.

Why is it important?

This work is part of the forward compatibility effort. We have to make sure users rely on the better solution for loading ML in Kibana, instead of the deprecated setup --machine-learning subcommand.

Checklist

  • My code follows the style guidelines of this project
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
    - [ ] I have made corresponding change to the default configuration files
    - [ ] I have added tests that prove my fix is effective or that my feature works it will come in a follow up PR
  • I have added an entry in CHANGELOG.next.asciidoc or CHANGELOG-developer.next.asciidoc.

@botelastic botelastic bot added the needs_team Indicates that the issue/PR needs a Team:* label label Sep 7, 2021
@kvch kvch added the Team:Elastic-Agent Label for the Agent team label Sep 7, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/agent (Team:Agent)

@botelastic botelastic bot removed the needs_team Indicates that the issue/PR needs a Team:* label label Sep 7, 2021
@elasticmachine
Copy link
Collaborator

elasticmachine commented Sep 7, 2021

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS
Pipeline View Test View Changes Artifacts preview preview

Expand to view the summary

Build stats

  • Start Time: 2021-10-06T13:14:46.681+0000

  • Duration: 152 min 59 sec

  • Commit: f5347df

Test stats 🧪

Test Results
Failed 0
Passed 54235
Skipped 5292
Total 59527

💚 Flaky test report

Tests succeeded.

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

  • /test : Re-trigger the build.

  • /package : Generate the packages and run the E2E tests.

  • /beats-tester : Run the installation tests with beats-tester.

@kvch kvch force-pushed the backward-compatibility-setup-ml-jobs branch from bd287c4 to a9c9da8 Compare September 8, 2021 11:08
@kvch
Copy link
Contributor Author

kvch commented Sep 8, 2021

Failing tests are unrelated.

@kvch kvch requested a review from ruflin September 8, 2021 15:02
@@ -392,6 +392,11 @@ func checkAvailableProcessors(esClient PipelineLoader, requiredProcessors []Proc

// LoadML loads the machine-learning configurations into Elasticsearch, if X-Pack is available
func (reg *ModuleRegistry) LoadML(esClient PipelineLoader) error {
if !mlimporter.IsCompatible(esClient) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Would it be also an option to return an error instead? Like this we make sure the user is aware of the change and can adjust the code.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What would be the expected action of the user? Change the setup command to exclude loading ML jobs?

What I have in mind is returning an error message when the user tried to load ML with the flag --machine-learning specified. Otherwise, just let them know that ML jobs are no longer loaded and do not return an error. WDYT?

Copy link
Collaborator

Choose a reason for hiding this comment

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

If a user runs the setup command, are the machine learning jobs installed by default? If yes, agree we should break this behaviour. If it is only if a flag was set manually either through config for command line flags, we should likely tell the user about it by erroring out. What I worry is that users will not look at the logs and will be surprised at one point that nothing is loaded. At the same time this is not "system critical" I would expect.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, it is loaded by default. I will add an error message for the case when users set machine learning explicitly.

@@ -417,6 +422,11 @@ func (reg *ModuleRegistry) LoadML(esClient PipelineLoader) error {

// SetupML sets up the machine-learning configurations into Elasticsearch using Kibana, if X-Pack is available
func (reg *ModuleRegistry) SetupML(esClient PipelineLoader, kibanaClient *kibana.Client) error {
if !mlimporter.IsCompatible(esClient) {
logp.Info("Skipping loading machine learning jobs because of Elasticsearch version is too new.\nIt must be 7.x for setting up it using Beats. Please use the Machine Learning UI in Kibana.")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Looks like the exact same error message as above but I assume the two functions do something slightly different based on the description? Same question for error instead of log.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, this function checks the ES version and the uses the Kibana client to load the ML jobs if it already has the required API.

@mergify
Copy link
Contributor

mergify bot commented Sep 10, 2021

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b backward-compatibility-setup-ml-jobs upstream/backward-compatibility-setup-ml-jobs
git merge upstream/7.x
git push upstream backward-compatibility-setup-ml-jobs

@kvch kvch force-pushed the backward-compatibility-setup-ml-jobs branch from a1a0d82 to 7dce2fe Compare September 14, 2021 14:46
Copy link
Collaborator

@ruflin ruflin left a comment

Choose a reason for hiding this comment

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

Do we have any tests in place in 7.x that check for the ml setup to work?

I'm looking forward to the follow up PR to remove the code completely!

func setupMLBasedOnVersion(reg *fileset.ModuleRegistry, esClient *eslegclient.Connection, kibanaClient *kibana.Client) error {
func setupMLBasedOnVersion(reg *fileset.ModuleRegistry, fromFlag bool, esClient *eslegclient.Connection, kibanaClient *kibana.Client) error {
if !mlimporter.IsCompatible(esClient) && fromFlag {
return fmt.Errorf("Machine learning jobs are not loaded because Elasticsearch version is too new. Use the Machine learning UI in Kibana.")
Copy link
Collaborator

Choose a reason for hiding this comment

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

Further down you mention that the version must be 7.x which is missing here.

@mergify
Copy link
Contributor

mergify bot commented Sep 28, 2021

This pull request is now in conflicts. Could you fix it? 🙏
To fixup this pull request, you can check out it locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

git fetch upstream
git checkout -b backward-compatibility-setup-ml-jobs upstream/backward-compatibility-setup-ml-jobs
git merge upstream/7.x
git push upstream backward-compatibility-setup-ml-jobs

@kvch kvch force-pushed the backward-compatibility-setup-ml-jobs branch from ab1ec1f to b19155b Compare October 6, 2021 11:41
@kvch kvch force-pushed the backward-compatibility-setup-ml-jobs branch from b19155b to f5347df Compare October 6, 2021 13:14
@kvch kvch merged commit b63fabd into elastic:7.x Oct 6, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Team:Elastic-Agent Label for the Agent team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants