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

Cherry-pick #8106 to 6.x: Adding xpack code for ES index recovery metricset #8137

Merged
merged 1 commit into from
Sep 7, 2018

Conversation

ycombinator
Copy link
Contributor

Cherry-pick of PR #8106 to 6.x branch. Original message:

This PR teaches the elasticsearch/index_recovery metricset to index index_recovery documents into .monitoring-es-6-mb-* indices. These documents should be compatible in structure to index_recovery documents in the current .monitoring-es-6-* indices indexed via the internal monitoring method.

// specific language governing permissions and limitations
// under the License.

package index_recovery

Choose a reason for hiding this comment

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

don't use an underscore in package name

@exekias
Copy link
Contributor

exekias commented Aug 29, 2018

Just saw there is no changelog either in this PR or the original one, is that intended?

@ycombinator
Copy link
Contributor Author

Just saw there is no changelog either in this PR or the original one, is that intended?

Yeah, it's intentional because we don't (yet) want to document the process of using Metricbeat to perform X-Pack monitoring. We'll do that once we have X-Pack monitoring via Metricbeat working for all Elastic products that are monitored today. Otherwise users can end up with a messy setup with only some products allowed to be monitored via Metricbeat and others still needing to do internal monitoring.

@ycombinator
Copy link
Contributor Author

jenkins test this

Copy link
Member

@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.

LGTM. Failing windows test is not related. @kvch is looking into it.

@ycombinator
Copy link
Contributor Author

@ruflin Thanks for noticing that. Just to double check: my plan is to wait till the 6.x branch CI is green again, then rebase this PR against 6.x so (hopefully) it goes green too. Correct?

@ruflin
Copy link
Member

ruflin commented Aug 31, 2018

@ycombinator Both options are ok for me. Either rebase when it's green or also now as the failing tests are not related.

* Adding index_recovery xpack monitoring documents

* Get all recoveries if xpack.enabled is true

* Removing newline (which also reordered imports)

* Don't reuse value so much

(cherry picked from commit f6b3e78)
@ycombinator
Copy link
Contributor Author

The only failure I'm seeing in CI for this PR is in the windows libbeat build:

10:07:32 Unit testing libbeat
10:08:11 exec : Unit test FAILURE
10:08:11 At C:\Users\jenkins\workspace\elastic+beats+pull-request+multijob-windows\beat\libbeat\label\windows\src\github.com\ela
10:08:11 stic\beats\dev-tools\jenkins_ci.ps1:49 char:1
10:08:11 + exec { Get-Content build/TEST-go-unit.out | go-junit-report.exe -set- ...
10:08:11 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
10:08:11     + CategoryInfo          : NotSpecified: (:) [Write-Error], WriteErrorException
10:08:11     + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Exec

This is the same failure that is currently occurring on CI for the target branch of this PR, 6.x (e.g. https://beats-ci.elastic.co/job/elastic+beats+6.x+multijob-windows/25/beat=libbeat,label=windows/console).

Also, this failure is unrelated to the code in this PR.

So I'm going to merge this PR now...

@ycombinator ycombinator merged commit 888a479 into elastic:6.x Sep 7, 2018
@ycombinator ycombinator deleted the backport_8106_6.x branch September 7, 2018 16:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants