add doc comments #53

Merged
lx merged 10 commits from trinity-1686a/garage:doc-comments into main 2021-04-08 13:01:22 +00:00

Add doc comments to the code
Feel free to correct if some doc-comments are inexact or missing because I did not understand what was happening

  • util
  • rpc
  • table
  • model
  • api
  • web
  • garage

Edit:
I was not able to comment everything as I did not understand every parts of the code

Some remarks:

  • some parts are especially hard to follow, garage_rpc::Ring::new for instance is too long to understand for me, enabling some linters in CI to check for such complex code would be nice (example: cargo clippy with cognitive_complexity on). In general having linters for code quality in CI helps a lot on long terme maintainability.
  • Short names for generic types are nice, until it's hard to understand what each type is supposed to do, such as in garage_table::schema::TableSchema
  • too much things are pub and should probably not be. For struct fields, it's hard to think in local invariant when a field can be modified from non local code. For structs and functions, exposing functions that should be private makes it harder to understand what is supposed to be used from outside, and what is not (also it makes for much more things to document)
  • style conventions (rustfmt) are not always respected, it should probably be checked in CI
  • no tests (yet)
Add doc comments to the code Feel free to correct if some doc-comments are inexact or missing because I did not understand what was happening - [x] util - [x] rpc - [x] table - [x] model - [x] api - [x] web - [x] garage Edit: I was not able to comment everything as I did not understand every parts of the code Some remarks: - some parts are especially hard to follow, `garage_rpc::Ring::new` for instance is too long to understand for me, enabling some linters in CI to check for such complex code would be nice (example: cargo clippy with [cognitive_complexity](https://rust-lang.github.io/rust-clippy/master/#cognitive_complexity) on). In general having linters for code quality in CI helps a lot on long terme maintainability. - Short names for generic types are nice, until it's hard to understand what each type is supposed to do, such as in `garage_table::schema::TableSchema` - too much things are pub and should probably not be. For struct fields, it's hard to think in local invariant when a field can be modified from non local code. For structs and functions, exposing functions that should be private makes it harder to understand what is supposed to be used from outside, and what is not (also it makes for much more things to document) - style conventions (rustfmt) are not always respected, it should probably be checked in CI - no tests (yet)
trinity-1686a force-pushed doc-comments from ada2027ae1 to 88705a009e 2021-03-22 00:19:04 +00:00 Compare
trinity-1686a changed title from WIP: add doc comments to add doc comments 2021-03-26 22:01:10 +00:00
lx requested changes 2021-03-27 15:10:59 +00:00
Dismissed
lx left a comment
Owner

Thank you trinity for the large amount of work on this PR. I have made a few comments at places where it seemed that there was misunderstandings of the code.

I'll say that globally the practice of adding a doc comment on everything seems abusive to me, as many such comments are strictly equivalent in information content (if not inferior) as the function name + type signature, and they have the inconvenient of reducing the information density of the code which I don't like (it's like a useless distraction taking up space on my screen). I prefer it when comments are reserved to cases where they bring significant insight to the code (which is the case of some comments in this PR). However if everyone thinks it's better to doc-comment everything I have no strong opposition to it being done. Let's just make sure these comments accurately reflect the high-level thinking behind the code and don't bring in any misconceptions and misunderstandings.

Thank you trinity for the large amount of work on this PR. I have made a few comments at places where it seemed that there was misunderstandings of the code. I'll say that globally the practice of adding a doc comment on everything seems abusive to me, as many such comments are strictly equivalent in information content (if not inferior) as the function name + type signature, and they have the inconvenient of reducing the information density of the code which I don't like (it's like a useless distraction taking up space on my screen). I prefer it when comments are reserved to cases where they bring significant insight to the code (which is the case of some comments in this PR). However if everyone thinks it's better to doc-comment everything I have no strong opposition to it being done. Let's just make sure these comments accurately reflect the high-level thinking behind the code and don't bring in any misconceptions and misunderstandings.
src/api/error.rs Outdated
@ -23,3 +29,4 @@
NotFound,
// Category: bad request
/// The request used an invalid path
Owner

the request contained an invalid UTF-8 sequence in its path or in other parameters would be more accurate

`the request contained an invalid UTF-8 sequence in its path or in other parameters` would be more accurate
trinity-1686a marked this conversation as resolved
src/api/error.rs Outdated
@ -52,6 +65,7 @@ impl From<roxmltree::Error> for Error {
}
impl Error {
/// Convert an error into an Http status code
Owner

rather get the HTTP status code that best represents the meaning of the error for the client

rather `get the HTTP status code that best represents the meaning of the error for the client`
trinity-1686a marked this conversation as resolved
src/api/lib.rs Outdated
@ -3,2 +5,3 @@
pub mod error;
mod error;
pub use error::Error;
Owner

Doesn't this prevent us from using OkOrBadRequest and OkOrInternalError? (haven't read what's below yet)

Doesn't this prevent us from using `OkOrBadRequest` and `OkOrInternalError`? (haven't read what's below yet)
Author
Owner

It prevents use from other crates, but not from this one. It does not break anything, but does prevent using those traits in web in the future, for instance ????

It prevents use from other crates, but not from this one. It does not break anything, but does prevent using those traits in web in the future, for instance ????
Owner

Alright, we'll make things pub again if/when we need them.

Alright, we'll make things `pub` again if/when we need them.
lx marked this conversation as resolved
@ -1,4 +1,6 @@
#![deny(missing_crate_level_docs, missing_docs)]
#![recursion_limit = "1024"]
//! Garage CLI, used to interact with a running Garage instance, and to launch a Garage
Owner

"and to launch a Garage instance" ?

"and to launch a Garage **instance**" ?
trinity-1686a marked this conversation as resolved
@ -142,3 +157,4 @@
}
/// Write a block to disk
pub async fn write_block(&self, hash: &Hash, data: &[u8]) -> Result<Message, Error> {
Owner

should probably not be pub, same for read_block and need_block

should probably not be `pub`, same for `read_block` and `need_block`
trinity-1686a marked this conversation as resolved
@ -230,2 +250,4 @@
}
/// Decrement the number of time a block is used
// when counter reach 0, it seems not put to resync which I assume put it to gc?
Owner

resync does both: if the rc is >0 and the block is not present, ask it to peers. on the contrary if rc=0 and block is present, delete it locally (after checking that no peer needs it)

resync does both: if the rc is >0 and the block is not present, ask it to peers. on the contrary if rc=0 and block is present, delete it locally (after checking that no peer needs it)
Author
Owner

I understand resync both get missing blocks and remove unnecessary blocks. My problem is that if I understand the code correctly, when the counter go down from 1 to 0, the value for new_rc is Some(0) (actually a Vec of 8 0u8), which is not None, so the block is not put to resync, and don't get deleted, unless some background thread regularly scan the table, which sound inneficient

I understand resync both get missing blocks and remove unnecessary blocks. My problem is that if I understand the code correctly, when the counter go down from 1 to 0, the value for new_rc is Some(0) (actually a Vec of 8 0u8), which is not None, so the block is not put to resync, and don't get deleted, unless some background thread regularly scan the table, which sound inneficient
Owner

block_decref actually deletes the value in the rc when it reaches 0, so it is indeed None and not Some(0), unless I'm mistaken? Maybe you're not looking at the last version of the code?

`block_decref` actually deletes the value in the rc when it reaches 0, so it is indeed None and not Some(0), unless I'm mistaken? Maybe you're not looking at the last version of the code?
Author
Owner

Nevermind, I somehow read old_v >= 1 instead of old_v > 1

Nevermind, I somehow read `old_v >= 1` instead of `old_v > 1`
trinity-1686a marked this conversation as resolved
@ -14,3 +15,4 @@
pub block: Hash,
// Sort key
// why a version on a hashed (probably immutable) piece of data?
Owner

version is the id of a Version object in the version table (which stores the different versions of objects in the buckets), not a version number for the BlockRef. i.e. BlockRef.version is the version id of an object that contains this block

version is the id of a Version object in the version table (which stores the different versions of objects in the buckets), not a version number for the BlockRef. i.e. `BlockRef.version` is the version id of an object that contains this block
trinity-1686a marked this conversation as resolved
@ -17,3 +19,4 @@
pub version: UUID,
// Keep track of deleted status
/// Is that block deleted
Owner

-> is the Version (a version of an object in a bucket) that contains this block deleted

-> is the Version (a version of an object in a bucket) that contains this block deleted
trinity-1686a marked this conversation as resolved
@ -60,15 +67,21 @@ impl BucketParams {
}
impl Bucket {
/// Create a new bucket
Owner

This formulation is ambiguous/misleading, as the bucket is not really created until the Bucket is commited to the database

This formulation is ambiguous/misleading, as the bucket is not really created until the `Bucket` is commited to the database
Owner

Suggestion: Initializes a new instance of the Bucket struct

Suggestion: `Initializes a new instance of the Bucket struct`
@ -67,2 +75,4 @@
}
}
/// Query if bucket is deleted
Owner

This formulation is ambiguous/misleading, as is_deleted does not do a database query, it just checks if this struct that was returned earlier from the db has the deleted flag

This formulation is ambiguous/misleading, as `is_deleted` does not do a database query, it just checks if this struct that was returned earlier from the db has the deleted flag
Owner

Suggestion: returns true if this represents a deleted bucket

Suggestion: `returns true if this represents a deleted bucket`
@ -102,1 +115,4 @@
fn updated(&self, _old: Option<Self::E>, _new: Option<Self::E>) {
// nothing to do when updated
}
Owner

did you remove the default empty implementation in the trait? was it a bad practice to have it?

did you remove the default empty implementation in the trait? was it a bad practice to have it?
Author
Owner

I would not necessarily call it bad practice.
It conveyed to me that "doing nothing" is a good default behavior, and while doing nothing might be a valid behavior, I think wanting to do nothing should be rather explicit.

I would not necessarily call it bad practice. It conveyed to me that "doing nothing" is a good default behavior, and while doing nothing might be a valid behavior, I think wanting to do nothing should be rather explicit.
Owner

(I answererd below)

(I answererd below)
lx marked this conversation as resolved
@ -20,3 +21,2 @@
// Authorized keys
/// Buckets in which the key is authorized. Empty if `Key` is deleted
pub authorized_buckets: crdt::LWWMap<String, PermissionSet>,
// CRDT interaction: deleted implies authorized_buckets is empty
Owner

this comment needs to be kept somewhere

this comment needs to be kept somewhere
trinity-1686a marked this conversation as resolved
@ -6,3 +7,3 @@
#[derive(PartialEq, Clone, Debug, Serialize, Deserialize)]
pub struct Key {
// Primary key
/// The id of the key (immutable)
Owner

please keep in the comment that this acts as the primary key

please keep in the comment that this acts as the primary key
trinity-1686a marked this conversation as resolved
@ -17,3 +18,3 @@
pub bucket: String,
// Sort key
/// The key at which the object is stored in its bucket
Owner

please keep in the comment that these two are used respectively as partition key (not primary key, my bad) and sort key, it's an import detail in understanding how Garage works internally

please keep in the comment that these two are used respectively as partition key (not primary key, my bad) and sort key, it's an import detail in understanding how Garage works internally
trinity-1686a marked this conversation as resolved
@ -20,3 +21,3 @@
pub key: String,
// Data
/// The list of known versions of the object
Owner

doesn't keep all known versions, the comment is misleading

doesn't keep all known versions, the comment is misleading
Author
Owner

I'm not sure what it store then

I'm not sure what it store then
trinity-1686a marked this conversation as resolved
@ -50,2 +53,4 @@
}
}
/// Get a list of all versions known for `Object`
Owner

s/known/currently stored

s/known/currently stored
trinity-1686a marked this conversation as resolved
@ -67,2 +77,4 @@
Uploading(ObjectVersionHeaders),
/// The version is fully received
Complete(ObjectVersionData),
/// The version was never fully received
Owner

it can never be received and stay in Uploading state forever if CompleteMultipartUpload/AbortMultipartUpload is never called (and it doesn't matter)

it can never be received and stay in Uploading state forever if CompleteMultipartUpload/AbortMultipartUpload is never called (and it doesn't matter)
trinity-1686a marked this conversation as resolved
@ -93,2 +105,4 @@
/// Data about an object version
#[derive(PartialEq, Eq, PartialOrd, Ord, Clone, Debug, Serialize, Deserialize)]
pub enum ObjectVersionData {
/// The version is deleted
Owner

the version represents a deletion of the object, i.e. at this version number the object doesn't exist (404)

the version represents a deletion of the object, i.e. at this version number the object doesn't exist (404)
trinity-1686a marked this conversation as resolved
@ -131,2 +159,4 @@
}
}
/// Is the object version available (received and not deleted)
Owner

is the object version available as an existing object (received and not a delete marker)

is the object version available as an existing object (received and not a delete marker)
trinity-1686a marked this conversation as resolved
@ -13,3 +14,3 @@
#[derive(PartialEq, Clone, Debug, Serialize, Deserialize)]
pub struct Version {
// Primary key
/// UUID of the version
Owner

used as a partition key

used as a partition key
trinity-1686a marked this conversation as resolved
@ -43,7 +49,9 @@ impl Version {
#[derive(PartialEq, Eq, Clone, Copy, Debug, Serialize, Deserialize)]
pub struct VersionBlockKey {
/// Number of the part, starting at 1
Owner

not necessarily starting at 1, the client decides the part numbers and we don't care (for instance he can send parts 0, 1, 2, 14, 22, 37 and 42, and that's a fine object as long as these parts match the checklist that is sent in the CompleteMultipartUpload call)

not necessarily starting at 1, the client decides the part numbers and we don't care (for instance he can send parts 0, 1, 2, 14, 22, 37 and 42, and that's a fine object as long as these parts match the checklist that is sent in the CompleteMultipartUpload call)
Author
Owner

Ok I've read s3 doc on multi-part upload and I hate it.
Next comment appear to be false too, it's offset in part, not in the whole file

Ok I've read s3 doc on multi-part upload and I hate it. Next comment appear to be false too, it's offset in part, not in the whole file
Owner

Yes, we don't know the offset in the whole file when a part is being uploaded because parts get uploaded independently from one another.

Yes, we don't know the offset in the whole file when a part is being uploaded because parts get uploaded independently from one another.
lx marked this conversation as resolved
@ -1,3 +1,4 @@
/// Module containing structs related to membership management
Owner

//!

`//!`
trinity-1686a marked this conversation as resolved
@ -78,28 +95,39 @@ pub struct System {
rpc_client: Arc<RpcClient<Message>>,
pub(crate) status: watch::Receiver<Arc<Status>>,
/// The ring, viewed by this node
Owner

not "viewed by this node", all nodes should have equal rings (if not it's a bug)

not "viewed by this node", all nodes should have equal rings (if not it's a bug)
trinity-1686a marked this conversation as resolved
@ -88,2 +108,4 @@
#[derive(Debug, Clone)]
pub struct Status {
/// Mapping of each node id to its known status
// considering its sorted regularly, maybe it should be a btreeset?
Owner

when is it sorted?

when is it sorted?
Author
Owner

it's sorted in recalculate_hash. Actually the node list is short, so sorting it is pretty much free

it's sorted in recalculate_hash. Actually the node list is short, so sorting it is pretty much free
Owner

That's my reasoning as well.

That's my reasoning as well.
lx marked this conversation as resolved
@ -90,1 +110,4 @@
/// Mapping of each node id to its known status
// considering its sorted regularly, maybe it should be a btreeset?
pub nodes: HashMap<UUID, Arc<StatusEntry>>,
/// Hash of this entry
Owner

hash of the whole set of currently known nodes. This hash is sent in regular ping messages so nodes can detect when they have different views of the cluster. They then exchange their peer lists kind of in an anti-entropy process.

hash of the whole set of currently known nodes. This hash is sent in regular ping messages so nodes can detect when they have different views of the cluster. They then exchange their peer lists kind of in an anti-entropy process.
trinity-1686a marked this conversation as resolved
@ -96,2 +121,4 @@
pub addr: SocketAddr,
/// Last time this node was seen
pub last_seen: u64,
/// Number of consecutive pings sent without reply to this node
Owner

Not sure but this counts failed requests of any kind, and not just ping messages. It is incremented in rpc_client.rs

Not sure but this counts failed requests of any kind, and not just ping messages. It is incremented in rpc_client.rs
Author
Owner

hum, it might double-count pings, as it count once in rpc_clients, and once in this file in ping_nodes

hum, it might double-count pings, as it count once in rpc_clients, and once in this file in ping_nodes
Owner

Thanks for noticing that, I'll have to check.

Thanks for noticing that, I'll have to check.
Owner

Ok so the cound in rpc_client does not happen when sending a ping message in ping_nodes in membership.rs because we are calling RpcAddrClient::call and not RpcClient::call (i.e. we are calling the node using its IP address and not its node identifier). The increment in rpc_client is done in RpcClient::call because it needs to know the node ID. So there is no redundancy between the two.

Ok so the cound in `rpc_client` does not happen when sending a ping message in `ping_nodes` in `membership.rs` because we are calling `RpcAddrClient::call` and not `RpcClient::call` (i.e. we are calling the node using its IP address and not its node identifier). The increment in `rpc_client` is done in `RpcClient::call` because it needs to know the node ID. So there is no redundancy between the two.
@ -341,3 +373,3 @@
addr,
sys.rpc_client
.by_addr()
.get_addr()
Owner

shouldn't be renamed to get_addr (see below)

shouldn't be renamed to `get_addr` (see below)
trinity-1686a marked this conversation as resolved
src/rpc/ring.rs Outdated
@ -1,3 +1,4 @@
//! Module containing types related to computing nodes which should receive a copy of data blocks
Owner

and metadata entries

and metadata entries
trinity-1686a marked this conversation as resolved
src/rpc/ring.rs Outdated
@ -23,2 +27,4 @@
/// The maximum number of time an object might get replicated
pub const MAX_REPLICATION: usize = 3;
/// The versionned configurations of all nodes known in the network
Owner

Not really, a node can be known in that it answers ping messages, and not be configured if it is idle or draining pending removal by admins.

Not really, a node can be known in that it answers ping messages, and not be configured if it is idle or draining pending removal by admins.
Author
Owner

would "available" be correct instead of known?

would "available" be correct instead of known?
Owner

Just put a TODO in the comment and I'll write it later

Just put a TODO in the comment and I'll write it later
Owner

Suggestion: The user-defined configuration of the cluster's nodes

Suggestion: `The user-defined configuration of the cluster's nodes`
src/rpc/ring.rs Outdated
@ -180,3 +197,4 @@
top >> (16 - PARTITION_BITS)
}
/// Get the list of partitions and
Owner

and the first hash (of a partition key) that would fall in this partition

and the first hash (of a partition key) that would fall in this partition
trinity-1686a marked this conversation as resolved
src/rpc/ring.rs Outdated
@ -193,6 +211,7 @@ impl Ring {
ret
}
/// Walk the ring to find the n servers in which data should be replicated
Owner

TODO rename this function as it doesn't walk the ring anymore but just returns the nodes at the corresponding location. This is vocabulary from the previous implementation that used datacenter-aware ring walking and led to data imbalance.

TODO rename this function as it doesn't walk the ring anymore but just returns the nodes at the corresponding location. This is vocabulary from the previous implementation that used datacenter-aware ring walking and led to data imbalance.
trinity-1686a marked this conversation as resolved
src/rpc/ring.rs Outdated
@ -201,12 +220,15 @@ impl Ring {
let top = u16::from_be_bytes(from.as_slice()[0..2].try_into().unwrap());
let partition_idx = (top >> (16 - PARTITION_BITS)) as usize;
// TODO why computing two time in the same way and asserting?
Owner

just to make sure I don't mess up. Should probably be factorized in a single location.

just to make sure I don't mess up. Should probably be factorized in a single location.
lx marked this conversation as resolved
@ -45,3 +52,4 @@
self.rs_timeout = timeout;
self
}
/// Set if requests can be dropped after quorum has been reached
Owner

as a general rule: true for read requests, false for write requests

as a general rule: true for read requests, false for write requests
trinity-1686a marked this conversation as resolved
@ -92,2 +105,3 @@
pub fn by_addr(&self) -> &RpcAddrClient<M> {
/// Get the server address this client connect to
pub fn get_addr(&self) -> &RpcAddrClient<M> {
Owner

Please don't call this get_addr, it's not what it does ! It does not return a SocketAddr or something like that. It is used to get the underlying RpcAddrClient which allows for RPC by specifing the target node's SocketAddr instead of their node IDs. Also, the comment is wrong.

Please don't call this `get_addr`, it's not what it does ! It does not return a SocketAddr or something like that. It is used to get the underlying RpcAddrClient which allows for RPC by specifing the target node's SocketAddr instead of their node IDs. Also, the comment is wrong.
trinity-1686a marked this conversation as resolved
@ -150,2 +167,4 @@
}
/// Make a RPC call to multiple servers, returning either a Vec of responses, or an error if
/// strategy could not be respected due to to many errors
Owner

too many*

too many*
trinity-1686a marked this conversation as resolved
@ -208,6 +227,7 @@ impl<M: RpcMessage + 'static> RpcClient<M> {
}
}
/// Endpoint to which send RPC
Owner

No. This is an RPC client which contains only the necessary logic to call RPC's to nodes by specifying their SocketAddr, and not by specifying their node IDs. It is used as an underlying layer for RpcClient.

No. This is an RPC client which contains only the necessary logic to call RPC's to nodes by specifying their SocketAddr, and not by specifying their node IDs. It is used as an underlying layer for RpcClient.
trinity-1686a marked this conversation as resolved
@ -14,2 +16,4 @@
fn write_nodes(&self, hash: &Hash) -> Vec<UUID>;
/// Responses needed to consider a write succesfull
fn write_quorum(&self) -> usize;
// this feels like its write_nodes().len() - write_quorum()
Owner

Most of the time it is, but not always for fully replicated tables

Most of the time it is, but not always for fully replicated tables
trinity-1686a marked this conversation as resolved
@ -4,7 +4,9 @@ use garage_util::data::*;
use crate::crdt::CRDT;
/// Trait for partitionnable data
Owner

It's not a trait for the data, but only for a field of the data that is used to partition it.

It's not a trait for the data, but only for a field of the data that is used to partition it.
trinity-1686a marked this conversation as resolved
@ -20,7 +22,9 @@ impl PartitionKey for Hash {
}
}
/// Trait for sortable data
Owner

Same as above, it's only a trait of one of the fields of the data

Same as above, it's only a trait of one of the fields of the data
trinity-1686a marked this conversation as resolved
@ -64,3 +77,3 @@
// due to CRDT logic. Typically errors in propagation of info should be logged
// to stderr.
fn updated(&self, _old: Option<Self::E>, _new: Option<Self::E>) {}
fn updated(&self, old: Option<Self::E>, new: Option<Self::E>);
Owner

Why remove empty implementation?

Why remove empty implementation?
Author
Owner

As explained above, I feel like a default implementation should be what we want in most case. Of 5 implementations of this trait, only 2 actually use an empty updated, so being explicit about it seems to me like a better option.

As explained above, I feel like a default implementation should be what we want in most case. Of 5 implementations of this trait, only 2 actually use an empty `updated`, so being explicit about it seems to me like a better option.
Owner

Idk, to me the reasonning was that updated() is implemented when we need to add logic to do something when an entry changes, but if we don't need to add anything we shouldn't have to write an empty updated() handler. I don't see how having an empty default implementation can cause much confusion as it does literally nothing.

Idk, to me the reasonning was that `updated()` is implemented when we need to add logic to do something when an entry changes, but if we don't need to add anything we shouldn't have to write an empty `updated()` handler. I don't see how having an empty default implementation can cause much confusion as it does literally nothing.
src/web/error.rs Outdated
@ -16,3 +20,3 @@
NotFound,
// Category: bad request
/// The client requested a malformed path
Owner

see garage_api/error.rs

see garage_api/error.rs
trinity-1686a marked this conversation as resolved
trinity-1686a force-pushed doc-comments from 4d83c5c0ff to c8906f200b 2021-04-06 03:29:01 +00:00 Compare
lx requested changes 2021-04-06 14:37:31 +00:00
Dismissed
lx left a comment
Owner

Make sure you check my answers on the previous review as well.

Make sure you check my answers on the previous review as well.
@ -387,2 +418,4 @@
} else if let Some(id) = id_option {
if let Some(st) = status.nodes.get_mut(id) {
// TODO this might double-increment the value as the counter is already
// incremented for any kind of failure in rpc_client
Owner

Actually no because the increment in rpc_client.rs is done by the RpcClient and not the RpcAddrClient, but here we are using the RpcAddrClient. (we could put this in a comment to make it clearer)

Actually no because the increment in `rpc_client.rs` is done by the `RpcClient` and not the `RpcAddrClient`, but here we are using the `RpcAddrClient`. (we could put this in a comment to make it clearer)
trinity-1686a added 1 commit 2021-04-07 11:39:48 +00:00
change some more comments and revert changes on TableSchema
All checks were successful
continuous-integration/drone/pr Build is passing
718ae00548
lx merged commit c35c472dc9 into main 2021-04-08 13:01:22 +00:00
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Deuxfleurs/garage#53
No description provided.