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

Introduce faucet subcommand #1357

Merged
merged 4 commits into from Feb 27, 2024
Merged

Conversation

jacderida
Copy link
Contributor

  • 11788e8 feat: provide faucet add command

    A new faucet subcommand is introduced, enabling the faucet to be controlled as a service. This is
    necessary because as with nodes, the faucet also needs to be upgraded on a new deployment; it may
    also require downgrading in the event of a problem.

    The existing faucet command, which was created as a utility for the backwards compatibility test,
    is removed; now that we can define the faucet as a service, it will no longer be necessary.

    The function that determines the data directory for the faucet was being duplicated in two different
    crates, and the node manager would have added a third, so it was refactored as public in
    sn_transfers and shared from there.

  • a319ebb feat: provide faucet start command

    This command is quite similar to the start command for starting a node service, but my judgement
    is there probably isn't enough code that is common between them to extract out something more
    generic.

    BREAKING CHANGE: the faucet_pid field of the node registry was removed in favour of a faucet
    field, which provides more details, including the PID.

  • 5e3b93c refactor: create a faucet_control module

    Rather than having a faucet module within node_control, I thought it made sense to also have a
    faucet_control module, and I've organised it the same as node_control.

  • 3a2a965 feat: provide faucet stop command

    As with the faucet start command, this provides the corresponding stop command. I revisited the
    idea of sharing code between the node and faucet services, but again came to the conclusion that
    there wasn't much value added for the complexity it introduced. The result is that we have code
    between them that only has small differences, but I think this is OK for now.

Description

reviewpad:summary

@jacderida jacderida changed the base branch from main to alpha February 27, 2024 14:22
A new `faucet` subcommand is introduced, enabling the faucet to be controlled as a service. This is
necessary because as with nodes, the faucet also needs to be upgraded on a new deployment; it may
also require downgrading in the event of a problem.

The existing `faucet` command, which was created as a utility for the backwards compatibility test,
is removed; now that we can define the faucet as a service, it will no longer be necessary.

The function that determines the data directory for the faucet was being duplicated in two different
crates, and the node manager would have added a third, so it was refactored as public in
`sn_transfers` and shared from there.
This command is quite similar to the `start` command for starting a node service, but my judgement
is there probably isn't enough code that is common between them to extract out something more
generic.

BREAKING CHANGE: the `faucet_pid` field of the node registry was removed in favour of a `faucet`
field, which provides more details, including the PID.
Rather than having a `faucet` module within `node_control`, I thought it made sense to also have a
`faucet_control` module, and I've organised it the same as `node_control`.
@jacderida jacderida force-pushed the faucet-subcmd branch 2 times, most recently from 1e2fe67 to c93dbc1 Compare February 27, 2024 15:09
///
/// There are several arguments that probably seem like they could be handled within the function,
/// but they enable more controlled unit testing.
pub async fn add_faucet(
Copy link
Member

Choose a reason for hiding this comment

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

This function can be made non-async.

let faucet_path =
get_bin_path(build, path, ReleaseType::Faucet, version, &*release_repo).await?;
let mut node_registry = NodeRegistry::load(&get_node_registry_path()?)?;
if let Some(faucet) = node_registry.faucet.clone() {
Copy link
Member

Choose a reason for hiding this comment

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

Just a tiny nit, but marking the var as mut can help us remove the following line, let mut faucet = faucet.

Suggested change
if let Some(faucet) = node_registry.faucet.clone() {
if let Some(mut faucet) = node_registry.faucet.clone() {

As with the `faucet start` command, this provides the corresponding `stop` command. I revisited the
idea of sharing code between the node and faucet services, but again came to the conclusion that
there wasn't much value added for the complexity it introduced. The result is that we have code
between them that only has small differences, but I think this is OK for now.
@RolandSherwin RolandSherwin added this pull request to the merge queue Feb 27, 2024
Merged via the queue into maidsafe:alpha with commit 0268a44 Feb 27, 2024
53 checks passed
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.

None yet

2 participants