-
Notifications
You must be signed in to change notification settings - Fork 2.5k
[meshery] feature: meshsync as a library #14799
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
[meshery] feature: meshsync as a library #14799
Conversation
…tation Signed-off-by: Nikita B <n2h9z4@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hello @n2h9, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
Summary of Changes
Hello! Gemini here, providing a summary of this pull request. This PR introduces a significant change by integrating MeshSync directly into Meshery Server as a library, rather than relying on a separate MeshSync deployment and an external NATS broker for communication. The core idea is to run MeshSync in-process and use Go channels to transport the discovered Kubernetes resource data. A temporary broker handler is implemented to bridge this channel-based communication with the existing data processing logic within Meshery Server.
Highlights
- MeshSync as a Library: MeshSync is refactored and integrated to run directly within the Meshery Server process, removing the dependency on an external MeshSync service.
- Internal Communication via Channels: Instead of using a NATS broker, MeshSync now communicates discovered data to Meshery Server using Go channels.
- Temporary Broker Handler: A new temporary broker handler (
TmpMeshsyncBrokerHandler
) is introduced to consume messages from the internal channel and feed them into the existing data handling flow, mimicking the broker interface. - Dependency Updates: The
go.mod
andgo.sum
files are updated to include a fork of the MeshSync repository, which presumably contains the library version.
Changelog
Click here to see the changelog
- go.mod
- Updated
github.com/layer5io/meshsync
from v0.8.6 to v0.8.8 (line 45). - Added a new dependency
github.com/n2h9/fork-meshery-meshsync
(line 51). - Added indirect dependency
github.com/myntra/pipeline
(line 263). - Removed indirect dependency
github.com/stretchr/objx
(line 290).
- Updated
- go.sum
- Updated checksums for
github.com/layer5io/meshsync
(lines 1331-1332). - Added checksums for
github.com/myntra/pipeline
(lines 1430-1431). - Added checksums for
github.com/n2h9/fork-meshery-meshsync
(lines 1432-1433). - Removed checksums for
github.com/stretchr/objx
.
- Updated checksums for
- server/models/meshery_controllers.go
- Changed import from
github.com/layer5io/meshkit/broker/nats
togithub.com/layer5io/meshkit/broker
(line 11). - Added import for the meshsync library fork
libmeshsync "github.com/n2h9/fork-meshery-meshsync/pkg/lib/meshsync"
(line 17). - Commented out the logic for connecting to the external Meshery Broker (NATS) (lines 93-119).
- Introduced a Go channel
transport
for internal communication (line 123). - Added a goroutine to run
libmeshsync.Run
with channel output configured (lines 125-143). - Replaced the NATS broker handler with
NewTmpMeshsyncBrokerHandler
using the internal channel (line 146).
- Changed import from
- server/models/tmp_meshsync_broker.go
- New file created to define
TmpMeshsyncBrokerHandler
(lines 1-72). - Implements a stub broker handler that reads messages from an internal channel in
SubscribeWithChannel
(lines 45-52).
- New file created to define
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command>
or @gemini-code-assist <command>
. Below is a summary of the supported commands.
Feature | Command | Description |
---|---|---|
Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/
folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist is currently in preview and may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments to provide feedback.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
A library's call,
Data flows through channel,
Broker takes a rest.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code Review
This pull request aims to integrate MeshSync as a library, which is a significant architectural shift. The changes involve updating dependencies to use a forked version of MeshSync and adapting the Meshery controller logic to use this library via a new temporary broker handler.
While the initiative to use MeshSync as a library is interesting, there are several points that need clarification and attention before this PR can be considered ready for merging. These primarily revolve around the use of a forked dependency, the temporary nature and incompleteness of the TmpMeshsyncBrokerHandler
, a hardcoded run duration for the MeshSync library, and general code hygiene like removing large blocks of commented-out code.
Please also ensure the PR description is updated to link the issue it fixes and that commits are signed as per repository guidelines.
Summary of Findings
- Use of Forked Dependency: The PR introduces
github.com/n2h9/fork-meshery-meshsync
. The rationale and long-term plan for this fork need clarification due to potential maintainability issues. - Temporary and Incomplete Broker Handler:
TmpMeshsyncBrokerHandler
appears to be a temporary or incomplete implementation, with a 'Tmp' prefix and several no-op or stubbed methods (e.g.,Publish
,Subscribe
,DeepCopy*
). This needs to be addressed for a production-ready solution. - Hardcoded MeshSync Library Duration:
libmeshsync.Run
is configured to stop after a fixed 64-second duration. This is unusual for a synchronization component and needs justification or correction if continuous operation is expected. - Lifecycle and Error Management of MeshSync Goroutine: The goroutine running
libmeshsync.Run
needs clearer lifecycle management (e.g., handling context cancellation) and potentially more robust error handling beyond logging. - Incorrect DeepCopy Implementation: The
DeepCopy*
methods inTmpMeshsyncBrokerHandler
do not perform deep copies, which could be problematic if true deep copy semantics are expected by consumers of thebroker.Handler
interface. - Commented-Out Code: Large sections of commented-out code in
server/models/meshery_controllers.go
should be removed to improve code clarity and maintainability.
Merge Readiness
This pull request introduces an interesting approach by using MeshSync as a library. However, due to the identified high
and medium
severity issues, particularly concerning the use of a forked dependency, the temporary nature and incompleteness of the TmpMeshsyncBrokerHandler
, the hardcoded run duration for the MeshSync library, and incorrect DeepCopy
implementations, I recommend that these changes not be merged in their current state.
Addressing these points will significantly improve the robustness, maintainability, and clarity of the proposed solution. I am unable to approve the pull request, and it should be reviewed by others once these concerns are addressed. Please also update the PR description with the relevant issue number and ensure commits are signed.
server/models/meshery_controllers.go
Outdated
go func() { | ||
duration := 64 * time.Second | ||
runOptions := make([]libmeshsync.OptionsSetter, 1) | ||
runOptions = append(runOptions, libmeshsync.WithOutputMode("channel")) | ||
runOptions = append(runOptions, libmeshsync.WithTransportChannel(transport)) | ||
runOptions = append(runOptions, libmeshsync.WithStopAfterDuration(duration)) | ||
|
||
err := libmeshsync.Run( | ||
mch.log, | ||
runOptions..., | ||
) | ||
if err != nil { | ||
mch.log.Warn(err) | ||
mch.log.Error( | ||
fmt.Errorf("error running meshsync lib %v", err), | ||
) | ||
} else { | ||
mch.log.Infof("meshkit run stops after %s", duration) | ||
} | ||
mch.log.Info(fmt.Sprintf("Meshery Broker unreachable for Kubernetes context (%v)", ctxID)) | ||
return mch | ||
} | ||
brokerHandler, err := nats.New(nats.Options{ | ||
// URLS: []string{"localhost:4222"}, | ||
URLS: []string{brokerEndpoint}, | ||
ConnectionName: MesheryServerBrokerConnection, | ||
Username: "", | ||
Password: "", | ||
ReconnectWait: 2 * time.Second, | ||
MaxReconnect: 60, | ||
}) | ||
if err != nil { | ||
mch.log.Warn(err) | ||
mch.log.Info(fmt.Sprintf("MeshSync not configured for Kubernetes context (%v) due to '%v'", ctxID, err.Error())) | ||
return mch | ||
} | ||
mch.log.Info(fmt.Sprintf("Connected to Meshery Broker (%v) for Kubernetes context (%v)", brokerEndpoint, ctxID)) | ||
token, _ := ctx.Value(TokenCtxKey).(string) | ||
msDataHandler := NewMeshsyncDataHandler(brokerHandler, *mch.dbHandler, mch.log, provider, userID, uuid.FromStringOrNil(k8scontext.ConnectionID), mesheryInstanceID, token) | ||
err = msDataHandler.Run() | ||
}() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The libmeshsync.Run
function is executed in a new goroutine.
- How is the lifecycle of this goroutine managed? For instance, if the
k8scontext
is removed or Meshery shuts down, is there a mechanism to gracefully stop this goroutine and ensurelibmeshsync
cleans up its resources? - Errors from
libmeshsync.Run
are logged, which is good. Are there any scenarios where errors might need to be propagated or handled in a more sophisticated way (e.g., retries, updating status for the user)?
Consider passing the ctx
to the goroutine and potentially to libmeshsync.Run
(if supported by the library) to allow for cancellation and better lifecycle management.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is an important comment.
Right now lifecycle of the go routine is not managed anyhow, it is supposed to be added later there is TODO in the code, when we implement switching mode.
propagation of error is not supposed in this implementation;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank you gemi 🤗
|
…ns list; update fork meshsync dependency Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
… as library Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
…ased on flag Signed-off-by: Nikita B <n2h9z4@gmail.com>
…ased on flag: return if broker handler is nil Signed-off-by: Nikita B <n2h9z4@gmail.com>
…agate the meshsync deployment mode flag from above Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
…o connections table, use during kubernetes ConnectAction state Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
Signed-off-by: Nikita B <n2h9z4@gmail.com>
We're in need of updating package references from github.com/layer5io/meshsync and layer5io/meshery-operator to meshery/meshsync and meshery/meshery-operator |
In my attempt to bump these references and bump to latest versions, I receive:
|
…rsion Signed-off-by: Nikita B <n2h9z4@gmail.com>
For this I have just opened a separate pr: #15134 |
And I also gave this updates a run with "Integration test with meshsync", here which gives some confidence that we didn't break anything. |
Signed-off-by: Lee Calcote <lee.calcote@layer5.io>
go.sum merge conflict fixed. Rebuilding.... |
Signed-off-by: Nikita B <n2h9z4@gmail.com>
…h9/forks-meshery-meshery into feature-meshsync-as-a-library
Commit SHA: END-TO-END TESTS
📦 Test Result Summary
⌛ Duration: 6 minutes and 4 seconds Overall Result: 👎 Some tests failed. [Show/Hide] Test Result Details
|
Revert "Merge pull request #14799 from n2h9/feature-meshsync-as-a-lib…
…as-a-library" This reverts commit ccdd508.
…as-a-library" This reverts commit ccdd508. Signed-off-by: Nikita B <n2h9z4@gmail.com>
Reapply "Merge pull request #14799 from n2h9/feature-meshsync-as-a-library
…as-a-library" This reverts commit ccdd508. Signed-off-by: Nikita B <n2h9z4@gmail.com>
Notes for Reviewers
This PR fixes implements usage of meshsync as a library according to the draft proposal;
Related prs on meshsync side:
Related prs on meshkit side:
Signed commits