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

Fix/refactormgrs #154

Merged
merged 7 commits into from
Mar 28, 2024
Merged

Fix/refactormgrs #154

merged 7 commits into from
Mar 28, 2024

Conversation

autodidaddict
Copy link
Contributor

When testing this locally, the v8 runner is rejecting the echofunction.js example with a reason of []. I don't know why this is happening and don't know if it's related to this PR or something else.

Elf binaries appear to work just fine.

@autodidaddict autodidaddict requested a review from a team as a code owner March 27, 2024 18:39
@autodidaddict
Copy link
Contributor Author

Now verified that this does indeed work with both elf and v8 binaries

Copy link
Contributor

@kthomas kthomas left a comment

Choose a reason for hiding this comment

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

The encapsulation provided by the Node -> MachineManager was to prevent us from breaking law of demeter. All of the new references now to m.node.* should be reconsidered.

@autodidaddict
Copy link
Contributor Author

The encapsulation provided by the Node -> MachineManager was to prevent us from breaking law of demeter. All of the new references now to m.node.* should be reconsidered.

yeah the whole point of me doing small refactoring PRs was to try and get incremental stuff done. Machine Manager in its current form is going away, in favor a WorkloadManager, which will encapsulate the workload management strategy and ultimately support both firecracker and firecrackerless process managers

/shrug

// }

func (m *MachineManager) agentLog(agentId string, entry agentapi.LogEntry) {
vm, ok := m.allVMs[agentId]
Copy link
Contributor

Choose a reason for hiding this comment

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

The map of VMs should still be indexed on vm id. Did we just wholesale rename vm id to agent id?

Instead, we should probably index these based on workload id. Which should come from the WorkloadManager eventually...

MachineId: vmID,
Text: entry.Text,
Level: slog.Level(entry.Level),
MachineId: agentId,
Copy link
Contributor

Choose a reason for hiding this comment

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

MachineId = agentId? My brain hurts.

import agentapi "github.com/synadia-io/nex/internal/agent-api"

// TODO: this will be utilized in a forthcoming PR
type ProcessManager interface {
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this meant to be what I was calling WorkloadManager?

Copy link
Contributor

Choose a reason for hiding this comment

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

I strongly suggest we call this WorkloadManager -- it does indeed seem to be that. I like this interface very much.

@@ -384,32 +384,6 @@ var _ = Describe("nex node", func() {
Expect(managerProxy.Telemetry()).To(Equal(nodeProxy.Telemetry()))
})

Describe("agent internal API subscriptions", func() {
Copy link
Contributor

Choose a reason for hiding this comment

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

These should all still be valid tests.


_, handshakeOk = m.handshakes[vmid]
time.Sleep(time.Millisecond * agentapi.DefaultRunloopSleepTimeoutMillis)
func (m *MachineManager) agentHandshakeTimedOut(agentId string) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Does this get called anywhere else other than awaitHandshake? If not, it makes it harder to read as a separate function.

What will the use-cases be to allow AgentClient instances to support this provided timeout callback?

@kthomas
Copy link
Contributor

kthomas commented Mar 27, 2024

The encapsulation provided by the Node -> MachineManager was to prevent us from breaking law of demeter. All of the new references now to m.node.* should be reconsidered.

yeah the whole point of me doing small refactoring PRs was to try and get incremental stuff done. Machine Manager in its current form is going away, in favor a WorkloadManager, which will encapsulate the workload management strategy and ultimately support both firecracker and firecrackerless process managers

/shrug

I actually think WorkloadManager should hold on to MachineManager in nearly its current form. Then we would be able to define a Manager interface, to be implemented by both MachineManager and AgentManager. This would allow us to do even smaller refactoring by keeping working code working, and simply tucking MachineManager behind a new WorkloadManager type.

Edit: that isn't to say that the branch isn't working after these changes 🙏🏻

@autodidaddict
Copy link
Contributor Author

That's pretty nearly what I plan. Review still says you're waiting for changes

@autodidaddict autodidaddict merged commit b275ed8 into main Mar 28, 2024
3 checks passed
@autodidaddict autodidaddict deleted the fix/refactormgrs branch March 28, 2024 16:18
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.

2 participants