-
Notifications
You must be signed in to change notification settings - Fork 87
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
Suzuka Deletion Util and Followers Test Cleanup #660
Conversation
}; | ||
|
||
// Split sync pattern on "<=>", expect exactly two parts (bucket and glob) | ||
let mut bucket_arrow_glob = sync_pattern_part.split("<=>"); |
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 also could use split_once
.
// Split sync pattern on "<=>", expect exactly two parts (bucket and glob) | ||
let mut bucket_arrow_glob = sync_pattern_part.split("<=>"); | ||
let bucket = bucket_arrow_glob.next().context( | ||
"MOVEMENT_SYNC environment variable must be in the format <bucket><=> <glob>", |
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 help is currently misleading due to a space on one side of the <=>
separator (it would be aesthetically better to separate also in front?), while the parsing code does not trim whitespace from the separated values.
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.
Do you want for me to trim?
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.
I think it's more robust to trim if whitespaces could be tolerated by the syntax, and it costs almost nothing.
@@ -0,0 +1,13 @@ | |||
#![forbid(unsafe_code)] |
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 only has effect on this binary, better add this directive to lib.rs
as well.
/*use movement_types::application; | ||
use syncup::{syncup, Target};*/ | ||
|
||
impl DotMovement { | ||
pub async fn sync( | ||
/*pub async fn syncup( |
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.
Please clean up the dead code or restore depending on the eventual intent.
|
||
pub async fn delete_sync_bucket( | ||
&self, | ||
bucket: String, | ||
) -> Result<impl std::future::Future<Output = Result<(), anyhow::Error>>, anyhow::Error> { | ||
let sync_task = | ||
syncup(false, self.0.clone(), "", Target::S3(bucket), application_id).await?; | ||
Ok(sync_task) | ||
}*/ |
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.
Is this also added as temporarily unused code?
pub async fn create_random_with_application_id( | ||
bucket: String, | ||
application_id: application::Id, | ||
pull_destination: PathBuf, | ||
) -> Result<(push::Push, pull::Pull), anyhow::Error> { |
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 proliferation of create_*
functions look like a builder API could be a better solution.
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.
I agree. Do you want that included in this PR?
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.
Not sure, this is not a blocker.
application_id: application::Id, | ||
pull_destination: PathBuf, | ||
) -> Result<(push::Push, pull::Pull), anyhow::Error> { | ||
pub async fn destroy_with_load_from_env(bucket: String) -> Result<(), anyhow::Error> { |
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 coupling of operation methods with a specific config load strategy is error-prone.
Consider something like this, maybe in conjunction with a builder pattern as suggested in the preceding comment:
let conn = BucketConnection::load_from_env("my_bucket").await?;
conn.destroy().await?;
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.
These helpers are being used for bucket operations from different processes, e.g., full node runtime and CLI.
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.
Does your comment still apply under that pretense?
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.
Yes, just perhaps a more composable API would be good where the loading of configuration from environment and connecting to AWS (the load_from_env
part) is common between the paths that create and destroy the specified bucket (the create
and destroy
methods, respectively). This also wraps the AWS API more closely.
bucket: String, | ||
pull_destination: PathBuf, | ||
metadata: metadata::Metadata, | ||
) -> Result<(push::Push, pull::Pull), anyhow::Error> { |
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.
I don't like how Push
, Pull
, and Metadata
need to be always imported tautologically as push::Push
, pull::Pull
, and metadata::Metadata
. I think it's better to re-export these names at this module level and make the push
, pull
, metadata
modules a private implementation detail.
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.
Okay, I will move them up.
Co-authored-by: Mikhail Zabaluev <mikhail.zabaluev@movementlabs.xyz>
|
…z/movement into l-monninger/deletion-util
Ah, committing that suggestion is probably why you had build issues @0xPrimata |
Summary
misc
.Creates a
suzuka-util
CLI. Provides a subcommand to delete a syncing resource. Uses said subcommand to clean up test sync buckets intest-followers
overlays.Testing
Easiest Way to Test the Deletion Util
MOVEMENT_SYNC
bucket:Check that an s3 bucket was created [INTERNAL ONLY]
Run the deletion util.
Tests Added
MOVEMENT_SYNC
parsing addded.process-compose
anddocker-compose
tests updated to include deletion.Outstanding issues