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

[NU-1777] Separate classloader for deployment managers #7335

Open
wants to merge 56 commits into
base: refactoring/NU-1777_nu_runtime_app
Choose a base branch
from

Conversation

coutoPL
Copy link
Member

@coutoPL coutoPL commented Dec 13, 2024

Describe your changes

  • deployment managers have a separate class loader (the Application ClassLoader is no longer used to load their classe
  • deployment manager class loader is a parent for the model class loader
  • you can configure paths for deployment managers using the managersDirs config setting
  • removed unused env used at the SBT level (includeFlinkAndScala)
  • new E2E test (example R-R scenario)

Checklist before merge

  • Related issue ID is placed at the beginning of PR title in [brackets] (can be GH issue or Nu Jira issue)
  • Code is cleaned from temporary changes and commented out lines
  • Parts of the code that are not easy to understand are documented in the code
  • Changes are covered by automated tests
  • Showcase in dev-application.conf added to demonstrate the feature
  • Documentation added or updated
  • Added entry in Changelog.md describing the change from the perspective of a public distribution user
  • Added MigrationGuide.md entry in the appropriate subcategory if introducing a breaking change
  • Verify that PR will be squashed during merge

@github-actions github-actions bot added the docs label Dec 13, 2024
@github-actions github-actions bot added client client main fe ui labels Dec 14, 2024
@coutoPL coutoPL marked this pull request as ready for review December 16, 2024 08:58
@@ -438,7 +456,8 @@ def assemblySettings(
includeScala: Boolean,
filterProvidedDeps: Boolean = true
): List[Def.SettingsDefinition] = {
// This work around need to be optional because for designer module it causes excluding of scala lib (because we has there other work around for Idea classpath and provided deps)
// This work around need to be optional because for designer module it causes excluding of scala lib
// (because we have there other work around for Idea classpath and provided deps)
Copy link
Member

Choose a reason for hiding this comment

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

Is it still relevant?

Copy link
Member Author

Choose a reason for hiding this comment

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

TBH I'm not sure what exact problem was solved this way and how to check if my change outdated it.

Copy link
Member

Choose a reason for hiding this comment

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

I see that false was passed only for designer assembly. It looks like we have a fat jar for designer. I don't know if someone uses it :) but ... The only provided dependencies of designer where DMs so the default filterProvidedDeps = true should work the same so we can remove this condition

build.sbt Outdated
Def
.taskDyn(if (addManagerArtifacts) distribution / managerArtifacts else Def.task[List[(File, String)]](Nil))
.taskDyn(
if (addManagerArtifacts) distribution / deploymentManagerArtifacts else Def.task[List[(File, String)]](Nil)
Copy link
Member

Choose a reason for hiding this comment

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

Won't we build some artefacts twice? I see that developmentTestsDeployManagerArtifacts contains also production artifacts now. Or sbt deduplicate them?

@@ -125,8 +128,6 @@ case class ClassLoaderModelData private (
override val additionalConfigsFromProvider: Map[DesignerWideComponentId, ComponentAdditionalConfig],
// This property is for easier testing when for some reason, some jars with ComponentProvider are
// on the test classpath and CPs collide with other once with the same name.
// E.g. we add liteEmbeddedDeploymentManager as a designer provided dependency which also
Copy link
Member

Choose a reason for hiding this comment

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

I would remove these functions now and whole comment block

Copy link
Member Author

Choose a reason for hiding this comment

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

I wanted to remove it but there is still some problem with ProcessConfigCreator implementations. Nevertheless, the lite Embedded deployment manager is not the problem anymore.

build.sbt Show resolved Hide resolved
build.sbt Outdated
@@ -2036,6 +2057,8 @@ lazy val designer = (project in file("designer/server"))
"io.circe" %% "circe-yaml" % circeYamlV % Test,
"com.github.scopt" %% "scopt" % "4.1.0" % Test,
"org.questdb" % "questdb" % "7.4.2",
"org.apache.kafka" % "kafka-clients" % kafkaV,
Copy link
Member

Choose a reason for hiding this comment

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

What's going on here?

Copy link
Member Author

Choose a reason for hiding this comment

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

TBH this dependency should be added at the component definition level (in the module when the kafka-related component/s is/are added). For some reason, there is no such dependency in the lite kafka component module (or one of the lite-related kafka modules). It's hard for me to unravel the relationships between these modules, so I decided to put the dependency here as well.

Screenshot 2024-12-16 at 23 07 20

Copy link
Contributor

Choose a reason for hiding this comment

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

the dependency was removed

build.sbt Outdated
@@ -2051,24 +2074,18 @@ lazy val designer = (project in file("designer/server"))
processReports,
security,
deploymentManagerApi,
componentsApi,
requestResponseComponentsApi,
Copy link
Member

Choose a reason for hiding this comment

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

and here

Copy link
Member Author

Choose a reason for hiding this comment

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

Designer and Runtime should define the API of components they are supposed to work with. And with these dependencies we express it.

Copy link
Member

@arkadius arkadius Dec 16, 2024

Choose a reason for hiding this comment

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

Yeah, but I thought that componentsApi is only necessary. These below have some engine-specific agreement that designer shouldn't be aware of

Copy link
Member Author

@coutoPL coutoPL Dec 16, 2024

Choose a reason for hiding this comment

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

Yes, so do I. But I got this when we don't add it:

Screenshot 2024-12-16 at 23 28 35

I wonder if engine<->designer separation is as good as the models/managers<->desinger one?

Copy link
Contributor

Choose a reason for hiding this comment

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

the dependencies were removed

@mk-software-pl mk-software-pl changed the base branch from staging to refactoring/NU-1777_nu_runtime_app January 10, 2025 10:38
Copy link
Contributor

created: #7410
⚠️ Be careful! Snapshot changes are not necessarily the cause of the error. Check the logs.

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

Successfully merging this pull request may close these issues.

3 participants