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

Optimize ockam node create #8755

Open
wants to merge 2 commits into
base: develop
Choose a base branch
from
Open

Conversation

SanjoDeundiak
Copy link
Member

No description provided.

@SanjoDeundiak SanjoDeundiak force-pushed the sanjo/node_callback branch 9 times, most recently from 357e149 to bb8b008 Compare January 16, 2025 20:59
@SanjoDeundiak SanjoDeundiak changed the title feat(rust): create tokio Runtime in a predictable way and reuse it WIP: clean tokio Runtime usage Jan 16, 2025
@SanjoDeundiak SanjoDeundiak force-pushed the sanjo/node_callback branch 8 times, most recently from ff99ca4 to e53013f Compare January 23, 2025 17:03
@SanjoDeundiak SanjoDeundiak force-pushed the sanjo/node_callback branch 2 times, most recently from 0e286be to 92b1064 Compare January 29, 2025 15:16
@SanjoDeundiak SanjoDeundiak changed the title WIP: clean tokio Runtime usage Optimize ockam node create Jan 29, 2025
@SanjoDeundiak SanjoDeundiak marked this pull request as ready for review January 29, 2025 15:18
@SanjoDeundiak SanjoDeundiak requested a review from a team as a code owner January 29, 2025 15:18
let cli_state = cli_state.set_tracing_enabled(tracing_configuration.is_enabled());

(tracing_configuration, tracing_guard, Some(cli_state))
};
Copy link
Member

Choose a reason for hiding this comment

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

what are the implications of not initializing the clistate here? Couldn't we initialize it here in both branches and remove the match cli_state from below?

Copy link
Member Author

Choose a reason for hiding this comment

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

The idea is to initialize logging as early as possible. The problem is that if tracing is enabled, we unfortunately need CliState to be able to properly bootstrap it. Therefore, I was able to initialize logging before creating the CliState only if tracing is disabled

@@ -45,6 +45,7 @@ after_long_help = docs::after_help(AFTER_LONG_HELP)
pub struct CreateCommand {
/// Name of the node or a configuration to set up the node.
/// The configuration can be either a path to a local file or a URL.
/// TODO: Use Option<String>
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 the context of this?

Copy link
Member Author

Choose a reason for hiding this comment

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

With current approach it's impossible to see if a user has passed "_default_node_name" or no value at all. Then later in the code you can see

if name == DEFAULT_NODE_NAME {
        name = random_name();
}

Which is now a hacky way to figure out if the user has provided no value. It would be a surprise for a user who provided "_default_node_name" and then ended up with a random node name, right? Not sure that's a realistic concern in this particular situation (due to low chance someone picking "_default_node_name" as the node name), but using Option would make it a clear distinction and as a consequence - easier to read the code.

// The default node was stopped, so we can reuse the name
name = default_node.name();
}
}
Copy link
Member

Choose a reason for hiding this comment

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

Why are these two checks removed, to prevent the clistate calls?

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 think the whole idea of node registry in the sqlite may need some improvements, but I haven't spent much time thinking about it. My main concern is that there are too many operations to achieve simple things, like starting a node. Ideally, creating a background node should not require opening the DB inside the parent process at all. Let's at least make small steps towards that. This check looked like something that doesn't give us much usability, but would slow us down each time we create a node. We need to admit that db calls are not free - they hurt latency, and start rethinking UX based on that. Also, let's maybe attempt replacing node registry and their status by getting information about running processes from the OS. That might turn out both faster and more reliable. WDYT about all of that?

Copy link
Member Author

Choose a reason for hiding this comment

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

Also, given default Vault, Identity, etc. creation is already performed by the background node, not the parent process, can we move some of these checks to the background node as well? That should get us to "parent node doesn't need db access" relatively easy. The ideal result would be that parent process only need to perform few things:

  1. Start the background ockam process
  2. Print output from that process
  3. Wait for the completion callback

@SanjoDeundiak SanjoDeundiak force-pushed the sanjo/node_callback branch 2 times, most recently from 16d64bf to c5925c0 Compare January 30, 2025 16:23
 - create tokio `Runtime` in a predictable way and reuse it
 - rework `Command` usage
 - add `no_logging` flag to the node
 - optimize node startup
 - replace readiness poll with a callback
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