-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Merge back with master #24746
Merged
Merged
Merge back with master #24746
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Translate global navigation bar component
We still backport to these branches, primarily for doc changes.
Replaces elastic#23301 Closes elastic#23080 --- This is a minimal threading implementation for Canvas. There's still a lot to be done to make this concept great, but this is a start. What it does: - Creates a server side abstraction on top of the interpreter - Determines where to send the expression by checking the first function to be run - Loads common functions in a separate worker thread on the server. - Routes to a single forked worker (thread), the main thread (server), or the browser (browser), in that order - Defers back to the router when a function isn't found. Fails if the function isn't found in any of the above 3 environments - Times out the worker if it takes too long, and respawns it as needed. - Simplifies the error dialog to remove the stack. What is does not.: - Round robin a pool of workers - Queue. If one expression in the threaded env fails then anything sent to it in the meantime will fail. The upstream environment handles managing timeouts. I think this would only make sense todo with a pool. - Client side. This doesn't implement web workers, but we could use roughly the same architecture. - Implement a specific, pluggable `worker` environment on the server. Right now it's just common functions, so plugin authors will always end up in a thread if they put their function in the common directory. What I don't like: - The socketProvider code. This was reused across the server & browser, but now that it's only used in the browser there's no good reason for the abstraction - The serialize/deserialize stuff feels messy. Do we really need serialization?
* Updates waterfall item design for timeline rows * Adjusts span and tx flyouts and updates tooltips to EUI * Heading size fixes and clean up * Updates tooltip snapshots * Review tweaks and snapshot updates * Revert experiment :) Co-Authored-By: jasonrhodes <[email protected]> * Fixes bug with v1 waterfall state * Fixes bug with timeline bar height * Updates snapshot tests * Updated test so it doesn't mount and rely on EUI makeId() which is non-deterministic per test run
This just tweaks the kbn-es error message to provide more context than just `Not Found`
…#24643) * [ML] Change file datavisualizer JSON format label to NDJSON * [ML] Update edit flyout overrides snapshot
translate Coordinate Map
add translations for region_map plugin
* [Tools] Add TemplateLiteral parsing to i18n_check tool * Add comments
Translate security/users
add translations for table vis plugin
translate new_nav_bar
…ntext (elastic#24705) * Fixes rare cases where KibanaLink will be loaded outside of React context and requires no redux connect dependency * Fixes tests for updated Kibana link component * Removes obsolete snapshot
* add basic structure for secops application * finalize skeleton for secops * fix type issue and hapi new version * remove route home, not needed for now * Add configuration + delete noise * prepend elastic license to generated file
elastic#24693) * Cut down on all tests except for secops tests and one example of infra integration tests * Commented out code for only this branch * Added comments and "please see issue number" * https://github.com/elastic/ingest-dev/issues/60
It's in the title, nevermind otherwise if the build just builds, I would imagine it will be good to go. |
FrankHassanabad
approved these changes
Oct 29, 2018
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As long as the build performs a build, this is good to go.
💚 Build Succeeded |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.