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

Add optimize and --no-optimize flags #16302

Merged
merged 8 commits into from
Sep 17, 2018
Merged

Conversation

jbudz
Copy link
Member

@jbudz jbudz commented Jan 25, 2018

This adds an optimize flag to bin/kibana and a no-optimize flag to bin/kibana-plugin. This doesn't change any current behavior beyond adding the new flags. If the optimize flag is used the server will not start after bundling.

@jbudz jbudz added review Team:Operations Team label for Operations Team labels Jan 25, 2018
@epixa
Copy link
Contributor

epixa commented Jan 25, 2018

Not against this, but it does seem like a breaking change

@jbudz jbudz changed the title [plugins] Remove optimization step [plugins installation] Move optimization step to server Jan 25, 2018
@jbudz jbudz changed the title [plugins installation] Move optimization step to server [plugin installation] Move optimize step to server Jan 25, 2018
@@ -30,8 +30,6 @@ export default async function install(settings, logger) {

await renamePlugin(settings.workingPath, path.join(settings.pluginDir, settings.plugins[0].name));

await rebuildCache(settings, logger);
Copy link
Contributor

Choose a reason for hiding this comment

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

What if we kept rebuildCache as the default, but added a skip-optimize or something like that would skip rebuild? Then users could opt into this. We could also document this as the "recommended approach", but we can't make it a default just yet because it would be a breaking change.

Copy link
Member Author

Choose a reason for hiding this comment

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

Thoughts on taking a separate approach for 6.x (if any)? I'm fine targeting this for 7.0 only even if it's getting removed.

I ask because we do have workarounds documented, but there's so many bin/plugin install guides that's its usually not followed.

Copy link
Member Author

Choose a reason for hiding this comment

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

Part of the reason I'm so heavy handed in this PR is I'm not sure why we bundle on plugin install. I've had suspicions that we went this way on v1 and never revisited, but if there's more context I'd love to hear it.

Copy link
Contributor

Choose a reason for hiding this comment

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

Targeting this for K7 is okey with me (even if that means making no changes to 6.x).

Copy link
Contributor

Choose a reason for hiding this comment

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

Let's do --skip-optimize for 6.x and --optimize for 7.0. Just make sure to add it to the breaking changes in master. And we should update all references in our docs to use --skip-optimize to help folks migrate to this pattern sooner.

Copy link
Contributor

Choose a reason for hiding this comment

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

Also, if you do what I just suggested, I strongly recommend making one PR that makes the --skip-optimize change to both master/6.x, then follow up with a PR that adds the --optimize argument, breaking change doc, and a clear error message when someone uses --skip-optimize

@jbudz
Copy link
Member Author

jbudz commented Jul 5, 2018

@elastic/kibana-operations I was about to close this out with #7322 as the approach but I wanted to throw up a refactor of this for a quick glance.

It's lower risk with no breaking changes, and when 7322 is in this would hopefully be a simple revert.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@jbudz jbudz requested a review from tylersmalley July 16, 2018 16:10
@tylersmalley
Copy link
Contributor

@jbudz want to make the changes mentioned in #16302 (comment) and we can move forward with this PR?

@jbudz
Copy link
Member Author

jbudz commented Aug 1, 2018

I can but that was how it was organized originally. I think the comment implies getting this merged and backported, and then opening a breaking PR to master on top of this one.

Either way not a problem, lemme know.

@jbudz
Copy link
Member Author

jbudz commented Aug 1, 2018

Updated the top level description to indicate current state, sorry about that.

@@ -47,6 +47,7 @@ export default function pluginInstall(program) {
.command('install <plugin/url>')
.option('-q, --quiet', 'disable all process messaging except errors')
.option('-s, --silent', 'disable all process messaging')
.option('--no-optimize', 'disable optimization after plugin extraction')
Copy link
Contributor

Choose a reason for hiding this comment

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

--skip-optimize was mentioned here, but I am OK with --no-optimize as the option.

Copy link
Contributor

Choose a reason for hiding this comment

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

++ for Commander convention.

@tylersmalley
Copy link
Contributor

@jbudz I pointed out one inconsistency with the feedback. Can we also update the docs as Court mentioned to use this option?

@jbudz jbudz changed the title [plugin installation] Move optimize step to server Add optimize and --no-optimize flags Aug 10, 2018
@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@tylersmalley
Copy link
Contributor

tylersmalley commented Sep 4, 2018

@jbudz this LGTM - just one more small ask. Can we remove --no-optimize from all of the commands in the docs and instead add a section similar to what we have done for --plugin-dir.

Something like:

Installing plugins while deferring optimization

The majority of the time spent installing a plugin is running the optimizer. If you're installing multiple plugins it can make sense to omit that step and only run it once. This can be done by providing --no-optimize to the plugin installation command. You can either execute bin/kibana --optimize to run the optimizer, or it will be ran the first time Kibana is started.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@elasticmachine
Copy link
Contributor

💔 Build Failed

@tylersmalley
Copy link
Contributor

@jbudz looks like this was caught by prettier.

17:53:14 ERROR kibana failed
17:53:14       /var/lib/jenkins/workspace/elastic+kibana+pull-request+multijob-intake/kibana/src/core/server/bootstrap.ts
17:53:14       ERROR: 89:21  prettier  Insert `;`

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💔 Build Failed

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@jbudz
Copy link
Member Author

jbudz commented Sep 17, 2018

I pushed three changes since the approval, tsc/lint/snapshot fixes. Merging away.

@jbudz jbudz merged commit f5d44f6 into elastic:master Sep 17, 2018
jbudz added a commit that referenced this pull request Sep 17, 2018
* Add optimize flags

* update docs to --no-optimize

* docs

* extra newline

* lint

* update mocks

* update default config

* update snapshots
@jbudz
Copy link
Member Author

jbudz commented Sep 17, 2018

6.x/5: 0eb4f58

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
review Team:Operations Team label for Operations Team v6.5.0 v7.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants