Skip to content
This repository has been archived by the owner on Jun 24, 2022. It is now read-only.

Support for plugin diffs + improved testing on minor upgrades + fixes #269

Merged
merged 5 commits into from
Mar 17, 2017

Conversation

gingerwizard
Copy link

@gingerwizard gingerwizard commented Mar 16, 2017

  1. ES is now 5.2.2
  2. Plugin diffing now occurs. If you remove or add plugins to the list, they will be uninstalled/installed respectively.
  3. Standard and multi test becomes the only idempotent test. Enhanced to install plugins with minor config changes for idempotent test.
  4. Config test confirms config changes if run multiple times. It also tests plugins can be removed and added.
  5. Package test confirms we can upgrade between minor versions and tests this with respect to plugins.
  6. Xpack tests check plugin upgrade between minor versions
  7. We now identify the installed plugins with a ls command. Resolves Plugin install fails on upgrade when es_plugins and es_xpack_features are used #213.

I would suggest we rename tests at some point to reflect their purpose. Standard should be enhanced to test more idempotent features. Also we can probably condense.

@gingerwizard
Copy link
Author

Ok the config test issues are due to a spelling mistake. The multi tests depend on jmespath - ill add to the provisonning and repush.

@gingerwizard
Copy link
Author

@jakommo @strootman @jpcarey mind reviewing.

- set_fact: list_command="list"
- set_fact: list_command=""
#If we are reinstalling all plugins, e.g. to a version change, we need to remove all plugins (inc. x-pack) to install any plugins. Otherwise we don't consider x-pack so the role stays idempotent.
- set_fact: list_command="| grep -vE 'x-pack'"
Copy link
Contributor

Choose a reason for hiding this comment

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

@gingerwizard I dont get why you exclude x-pack here. Specially how this makes it idempotent.

Copy link
Author

Choose a reason for hiding this comment

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

Normally we don't want to consider x-pack in deltas of plugins - as its handled by a seperate task later. However, if we are doing a complete re-install e.g. version change, we are forced to uninstall it in order to install any other plugins.

Copy link
Author

Choose a reason for hiding this comment

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

The later x-pack task will inturn install it again. This was a workaround until we refactor the x-pack handling in the role - which id like to do but suspect it will be very disruptive.

Copy link
Contributor

Choose a reason for hiding this comment

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

humm! understood. But for the x-pack installation, why can't we just add x-pack to the es_plugins list? In that way, all plugins are managed the same way and avoid code duplication.

Copy link
Contributor

@barryib barryib Mar 17, 2017

Choose a reason for hiding this comment

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

maybe latter with the x-pack refactoring? Or even let the user add into the plugins list he wants to manage.

Copy link
Author

Choose a reason for hiding this comment

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

indeed thats the plan but it meant touching more beyond the remit of this PR. I think its reasonable to want to do this in one place though - although the x-pack stuff does alot more.

@gingerwizard
Copy link
Author

@jpcarey changes caused a build and 2 failures. These are hard to reproduce and seem to occur intermittently and are associated with templates and auth - this is subject to a rewrite shortly. Lets see if they occur,

jenkins, test it

@gingerwizard
Copy link
Author

Actually its because when we go up versions we have to uninstall x-pack which might be causing users to be dropped....

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants