Fix bug in xpackInfo in which keys were being camel-cased during refresh but not init#29304
Conversation
…esh but not init.
|
Tagging Shaunak for review because he originally introduced the camel-casing logic in X-Pack. |
💔 Build Failed |
|
I don't know the full context of this PR but I can certainly try to explain a bit of history on where the camel-casing logic came from, if that might help: At the time the xpackInfo functionality was developed (circa June 2016 IIRC), Kibana had a convention of using Hope that helps! |
|
Seems to me we often still try to keep this convention. So for that reason I would lean to BeatsCM changing. Just curious if that’s a convention we WANT to keep, or one we have kept just because. |
|
@mattapperson Sounds good, I agree. Would you mind submitting a PR into this one to update Beats? |
|
CI should go green once Beats is updated. |
[BeatsCM] Change settings path
💔 Build Failed |
|
Retest |
💔 Build Failed |
💚 Build Succeeded |
|
CI went green and I only pushed a code comment, so I'm going to merge without waiting for CI to pass again. |
💚 Build Succeeded |
…esh but not init (elastic#29304) * Update Beats Management to use camelCased plugin ID to access xpackInfo.
This fixes a bug in a CCR feature we're working on, but introduces an error in Beats Management:
This error comes from this line: https://github.com/elastic/kibana/blob/master/x-pack/plugins/beats_management/public/lib/adapters/framework/kibana_framework_adapter.ts#L114
It stems from the fact that Beats Management attempts to retrieve xpackInfo using its plugin ID,
beats_management.I can think of a couple solutions: