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

Get the grains that we check on every startup from the start event #1833

Merged
merged 8 commits into from
Feb 25, 2020

Conversation

admd
Copy link
Contributor

@admd admd commented Jan 27, 2020

What does this PR change?

Get the grains (machine_id, saltboot_initrd, management_key) that we check on every startup from the start event instead of making a separate call.

Background

We faced performance issues during minions startup as machine_id grains is needed to lookup if minion already exists in the database. This is needed to differentiate between a startup and 1st-time registration.

We followed different approaches, each with some pros/cons. Those approaches are described herein this PR description https://github.com/SUSE/spacewalk/pull/8892. The related research card is https://github.com/SUSE/spacewalk/issues/8228 where one can see further discussion.

In the end, we introduced a patch in upstream which makes it possible to pass interesting grains in the payload of minion start-up event. Related PR saltstack/salt#54948.
We think this is better approach in a sense that, we don't need to make a separate call, of course, it has a downside that all the minions need to have this new parameter in their config so next time, when minion get started, we use grains from the start_up event instead of making a separate call.

It is also noticeable that I kept the old way as a fallback, the reason was the older minions might not get the new changes so we have to have a backup plan.

We save 1 salt call in case of already registered minions, even if startup grains are not configured.

So if start-up grains are supported, with this PR number of salt sync calls are following

Test Before After
New registration 2 1
Registered minion startup 2 0

If start-up grains are not supported, with this PR number of salt sync calls are following

Test Before After
New registration 2 2
Registered minion startup 2 1

Benchmarks

According to tests with 100 evil-minions at normal speed mode (--slowdown-factor 1) an ~1.32x speedup on the total time to handle all minion start events (29s on average versus 38.5s).

Note that it is expected that the slower the simulated minions, the bigger the speedup.

GUI diff

No difference.

  • DONE

Documentation

-Instead of a separate call, the grain is part of startup event, there is nothing to document here for the customer. I will add the documentation for using the helper `mgr_start_event_grains.sls state though
uyuni-project/uyuni-docs#88

  • DONE

Test coverage

  • No tests: Existing tests are modified

  • DONE

Links

Fixes # https://github.com/SUSE/spacewalk/issues/9909
Tracks # add downstream PR, if any

  • DONE

@admd admd force-pushed the use-grains-passed-at-startup branch 4 times, most recently from 4a8bbec to 3eeecaa Compare January 27, 2020 12:46
@admd admd changed the title Get the machine-id grain from the start up event [WIP]Get the machine-id grain from the start up event Jan 27, 2020
@admd admd force-pushed the use-grains-passed-at-startup branch from 3eeecaa to e400c30 Compare January 28, 2020 13:42
@moio
Copy link
Contributor

moio commented Jan 29, 2020

@admd please remove the [WIP] tag from the title and re-request my review when ready

@admd admd force-pushed the use-grains-passed-at-startup branch from e400c30 to 69307d1 Compare January 30, 2020 10:32
@admd admd changed the title [WIP]Get the machine-id grain from the start up event Get the machine-id grain from the start up event Jan 30, 2020
@admd admd requested review from aaannz and moio and removed request for moio January 30, 2020 10:40
Copy link
Contributor

@moio moio left a comment

Choose a reason for hiding this comment

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

Additional points:

  1. WRT documentation: shouldn't we add an indication how to use susemanager-utils/susemanager-sls/salt/util/mgr_start_event_grains.sls? I guess it could be similar to what we added for the Salt mine or the fqdns grain

  2. how do we make sure this new configuration is added by default on all new minions? We would need:

All of the above can optionally go into separate PRs linked from here. But I would not consider this whole "work item" done without them.

  1. tests: that existing tests are modified is definitely needed, but I would also suggest adding at least minimal coverage to new code (eg. RegisterMinionEventMessage with non-empty grains parameter). I would say this needs addressing in this PR.

  2. performance: I would really like to see some before/after numbers, maybe generated via evil-minions. How much do we gain in handling the startup event of, say, 1000 minions? Please contact me for any evil-minions questions, I am not sure the tool can be used as it is now to perform the test for this PR.

Meta: it was very difficult to review RegisterMinionEventMessageAction.java - not sure if it would have been possible, but splitting the change in multiple commits could have helped reviewers here, please keep in mind for next time. While you are fixing the code, double check that core logic in this file has not really changed with the refactorings that were necessary here.

@admd admd changed the title Get the machine-id grain from the start up event Get the grains that we check on every startup from the start event Feb 4, 2020
@admd
Copy link
Contributor Author

admd commented Feb 4, 2020

Thank you @moio for the review. I really overlooked some part. I have made the suggested changed. Please have a look. Now the only remaining part is the PR for sumaform & for doc. I will create them in a while.

@admd admd requested a review from moio February 4, 2020 16:53
Comment on lines 259 to 285
String oldMinionId = registeredMinion.getMinionId();
if (!minionId.equals(oldMinionId)) {
LOG.warn("Minion '" + oldMinionId + "' already registered, updating " +
"profile to '" + minionId + "' [" + registeredMinion.getMachineId() + "]");
registeredMinion.setName(minionId);
registeredMinion.setMinionId(minionId);
ServerFactory.save(registeredMinion);
SystemManager.addHistoryEvent(registeredMinion, "Duplicate Machine ID", "Minion '" +
oldMinionId + "' has been updated to '" + minionId + "'");

SALT_SERVICE.deleteKey(oldMinionId);
Copy link
Contributor

Choose a reason for hiding this comment

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

As you are touching this code, can you take a look at #1835, please.

Copy link
Contributor

@moio moio left a comment

Choose a reason for hiding this comment

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

OK, this reads muuuch better now, thanks!

I still left a few remarks, of which only one is really important at this point.

Thanks for your perseverance!

@admd
Copy link
Contributor Author

admd commented Feb 5, 2020

Thank you @moio for the review. I have added 2 more commits with the changes. You can review them separately.

Copy link
Contributor

@moio moio left a comment

Choose a reason for hiding this comment

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

LGTM, thanks for all the efforts here.

Please do run benchmarks on this and make sure you add a Speedup line in the PR's description.

Optional<ActivationKey> activationKey =
mkey.flatMap(mk -> ofNullable(ActivationKeyFactory.lookupByKey(mk)));
Optional<String> validReactivationKey =
mkey.flatMap(mk -> isValidReactivationKey(activationKey, minionId) ? mkey : empty());
Copy link
Contributor

Choose a reason for hiding this comment

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

Style nitpick: Optional supports filter

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Changed it. 👍

@admd admd force-pushed the use-grains-passed-at-startup branch from d5917f6 to ae33f6b Compare February 18, 2020 09:53
@admd admd requested a review from mcalmer February 18, 2020 09:56
Copy link
Contributor

@mcalmer mcalmer left a comment

Choose a reason for hiding this comment

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

failing tests. Better to rebase and fix the tests first

@admd admd force-pushed the use-grains-passed-at-startup branch from ae33f6b to 483e566 Compare February 21, 2020 10:31
@admd
Copy link
Contributor Author

admd commented Feb 21, 2020

@mcalmer I have rebased the branch & you can review it now. There is some untreated rubocop error but rest should be fine.

Copy link
Contributor

@mcalmer mcalmer left a comment

Choose a reason for hiding this comment

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

Let's give it a try.

@admd admd force-pushed the use-grains-passed-at-startup branch from 483e566 to acb0b9a Compare February 21, 2020 14:11
@mcalmer
Copy link
Contributor

mcalmer commented Feb 21, 2020

@admd a rebase should also solve most of the failing tests now.

@admd admd force-pushed the use-grains-passed-at-startup branch from acb0b9a to 8cddc59 Compare February 21, 2020 15:14
@moio moio force-pushed the use-grains-passed-at-startup branch 2 times, most recently from 69307d1 to a0d897b Compare February 25, 2020 08:00
@moio moio merged commit ee453d9 into uyuni-project:master Feb 25, 2020
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.

4 participants