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

Refactor data node startup, add startup mechanism for new node types #20181

Merged
merged 46 commits into from
Dec 12, 2024

Conversation

moesterheld
Copy link
Contributor

Description

Modifies the CmdLineTool to allow configurable startup of new node types.
A GraylogNodeConfiguration interface configures certain whether certain common startup features should be run.
For a node incorporating the features we deem as common, a CommonNodeConfiguration is provided which sets these flags as default.

Data node startup has been changed to use the refactored CmdLineTool directly, setting the necessary features as required by the data node. Additionally, bootstrapping of the data node has been revamped. This does not completely decouple the startup logic from Graylog startup, but uses a common codebase instead of the previously duplicated code.

An example node is currently included in the PR to showcase how new node types can be created (ExampleCommand). This should be removed before merging.

/nocl

Motivation and Context

solves #18908
solves #18011

How Has This Been Tested?

run data node, Graylog, certutil, journal commands manually

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Refactoring (non-breaking change)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.

@moesterheld moesterheld requested a review from todvora August 16, 2024 14:46
Copy link
Contributor

@todvora todvora left a comment

Choose a reason for hiding this comment

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

Tested locally, works fine and the code seems good to me. But it's still a draft and we need somebody from architecture to look at this, so only commenting, not approving for now.

@moesterheld moesterheld marked this pull request as ready for review October 18, 2024 09:58
@moesterheld moesterheld requested a review from bernd October 18, 2024 15:09
Copy link
Member

@bernd bernd left a comment

Choose a reason for hiding this comment

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

A first quick review. Will do testing and a more detailed review next.

Copy link
Member

@bernd bernd left a comment

Choose a reason for hiding this comment

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

Thanks! A few comments.

@moesterheld
Copy link
Contributor Author

@bernd I addressed your comments.
I also cleaned up the redundant bindings and made all commands, including the cli commands use the AbstractNodeCommand. The only redundant bindings are now for preflight. In the future, we could think about making preflight bindings configurable from a GraylogNodePreflightModule and/or getPreflightCommandBindings methods in the AbstractNodeCommand.

@moesterheld moesterheld requested a review from bernd December 5, 2024 14:42
Copy link
Member

@bernd bernd left a comment

Choose a reason for hiding this comment

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

I left two pings in comments that haven't been answered. (or I didn't see it)

@moesterheld moesterheld requested a review from bernd December 10, 2024 14:26
moesterheld and others added 2 commits December 10, 2024 15:26
# Conflicts:
#	data-node/src/main/java/org/graylog/datanode/bindings/PreflightChecksBindings.java
Copy link
Member

@bernd bernd left a comment

Choose a reason for hiding this comment

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

Thank you! 🙏

@moesterheld moesterheld merged commit b4e1e07 into master Dec 12, 2024
6 checks passed
@moesterheld moesterheld deleted the refactor/abstract-node-startup branch December 12, 2024 15:02
install(new ServerStatusBindings(configuration.withCapabilities()));

bind(EncryptedValueService.class).asEagerSingleton();
bind(InputConfigurationBeanDeserializerModifier.class).toInstance(InputConfigurationBeanDeserializerModifier.withoutConfig());
Copy link
Contributor

Choose a reason for hiding this comment

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

@moesterheld: For the server, this binding breaks the saving of inputs that contain encrypted values. You can reproduce it by creating an AWS CloudTrail where you only set the title (and node) and leave everything else empty. You can save it, but afterwards the inputs page is broken and you have to remove the input manually from MongoDB.

We should either go back to a just-in-time binding (for the server) or do a regular singleton scope binding. I didn't test the latter but it should be fine.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks @thll , I will fix this and try to add an automated test that covers this somehow.

Copy link
Contributor

Choose a reason for hiding this comment

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

Thank you! Yeah, having some kind of integration test for this would be great as the cause is very subtle and hard to find.

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

Successfully merging this pull request may close these issues.

4 participants