-
Notifications
You must be signed in to change notification settings - Fork 115
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
[Origo] Adds support to mark storage-node/distrubtion-node under maintenance #4793
base: master
Are you sure you want to change the base?
[Origo] Adds support to mark storage-node/distrubtion-node under maintenance #4793
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎ 1 Ignored Deployment
|
…sus_operational_status_feat
You need to add implicitly new dependency on inquirer-datepicker? (and maybe others) to storage node: this is why this check is failing building docker image for storage node https://github.com/Joystream/joystream/actions/runs/5561050023/jobs/10158465896?pr=4793#step:8:373 |
Integration tests will be added in #4815 |
@Zeeshan perhaps we can try to bump version of |
…sus_operational_status_feat
2063272
to
b07bbec
Compare
Bumped package versions and updated CHANGELOG.md in d133ffb |
Great. |
5cf5bd6
to
d133ffb
Compare
Done in ba24cfe |
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.
Great work @zeeshanakram3 and sorry for doing this review so late 🙇 I think one additional feature we could introduce is for distribution nodes to only query active storage operators when doing pings/asset checks. But we can do that as a followup later, this in itself is quite valuable.
Edit: I see that issue for that is already created and scoped: #4816
} | ||
|
||
// Node's Operational status to set | ||
optional OperationalStatus status = 1; |
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.
Shouldn't the status
be required here? Full NodeOperationalStatusMetadata
is already optional in DistributionBucketOperatorMetadata
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.
@zeeshanakram3 still relevant
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 would go further and suggest that we should probably have multiple messages, corresponding with the options in the commands for setting the metadata.
message NodeOperationalStatusNormal {
optional string rationale = 1;
required string bucketId = 2;
}
message NodeOperationalStatusNoService {
optional string rationale = 1;
required string bucketId = 2;
}
NodeOperationalStatusNoServiceFrom {
optional string rationale = 1;
required string from = 2; // date
required string bucketId = 3;
}
NodeOperationalStatusNoServiceUntil {
optional string rationale = 1;
optional string from = 2 // date
required string until = 3; // date
required string bucketId = 4;
}
Doing this I think will help address a couple issues raised in other places in the review as well as simplifying implementation in the commands and squid mappings I presume.
if ((await getWorker(store, workingGroup.name, workerId)) === undefined) { | ||
return invalidMetadata(`The worker ${workerId} does not exist in the ${workingGroup.name} working group`) | ||
} |
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'm wondering, do we need to bother with worker for storage buckets? Those only have a single operator so I guess the worker ID doesn't make any difference?
status.from = new Date(meta.noServiceFrom) | ||
status.to = new Date(meta.noServiceTo) |
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.
Are those raw dates validated anywhere? If not, we probably should do that
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.
Addressed this in storage squid PR Joystream/storage-squid#19
### SPECIFIC DATA ### | ||
|
||
"Storage Bucket" | ||
storageBucket: StorageBucket |
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.
Shouldn't that be a required field?
storage-node/src/commands/leader/set-node-operational-status.ts
Outdated
Show resolved
Hide resolved
metadata = { | ||
...input, | ||
operationalStatus: { | ||
...input.operationalStatus, | ||
status: | ||
input.operationalStatus?.status === 'Normal' | ||
? NodeOperationalStatusMetadata.OperationalStatus.NORMAL | ||
: NodeOperationalStatusMetadata.OperationalStatus.NO_SERVICE, | ||
}, | ||
} |
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 if somebody will try to set metadata without operational status then this will set it to NO_SERVICE
?
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.
Addressed in 6ff4531
metadata = { | ||
...params, | ||
operationalStatus: { | ||
...params.operationalStatus, | ||
status: | ||
params.operationalStatus?.status === 'Normal' | ||
? NodeOperationalStatusMetadata.OperationalStatus.NORMAL | ||
: NodeOperationalStatusMetadata.OperationalStatus.NO_SERVICE, | ||
}, |
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 if somebody will try to set metadata without operational status then this will set it to NO_SERVICE
?
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.
Addressed in 6ff4531
@@ -957,6 +962,9 @@ type DistributionBucketOperatorMetadata implements BaseGraphQLObject { | |||
nodeLocation: NodeLocationMetadata | |||
nodeLocationId: String | |||
|
|||
"""Optional node operational status""" | |||
nodeOperationalStatus: NodeOperationalStatus |
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 this can be hard to query because of QN nested filtering limitations. I think we need to design a schema in a way that I can easily fetch all the active operators. If I'm not mistaken with the current schema the query would have to be (paraphrasing, I don't remember the query syntax for checking specific union type):
query {
distributionBucketOperators(
where: { metadata: { nodeOperationalStatus: { status: "OKAY" } } }
) {
id
}
}
And that filter would be too deep for QN to execute. Same applies to storage buckets
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.
Also, would it be possible to make operational status required part of metadata? Because empty operational status currently would also mean "Okay" but it would be hard to query it I think
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 you would not have that problem with storage squid's graphql server
const leadKey = await this.getDistributorLeadKey() | ||
|
||
let operationalStatus: INodeOperationalStatusMetadata = {} | ||
switch (statusType) { |
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.
statusType
input is not required, should we default to Normal
?
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.
It makes more sense to make it required, the command name doesn't imply what the default value should be.
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.
It makes more sense to make it required, the command name doesn't imply what the default value should be.
Done
const workerKey = await this.getDistributorWorkerRoleKey(workerId) | ||
|
||
let operationalStatus: INodeOperationalStatusMetadata = {} | ||
switch (statusType) { |
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.
Same question about default status here
? NodeOperationalStatusMetadata.OperationalStatus.NORMAL | ||
: NodeOperationalStatusMetadata.OperationalStatus.NO_SERVICE, | ||
} | ||
: {}, |
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.
Would this override the current status? Or skip the update?
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.
It should skip the update but previously it was overriding, I have fixed it
operatorMetadata: { | ||
OR: [ | ||
{ nodeOperationalStatus_isNull: true } | ||
{ nodeOperationalStatus: { isTypeOf_eq: "NodeOperationalStatusNormal" } } |
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 filter would skip any nodes with future maintenance as well. We probably should get all the operators and later only filter those that are under maintenance currently
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.
Done in 0537ee7
} | ||
|
||
// Node's Operational status to set | ||
optional OperationalStatus status = 1; |
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.
@zeeshanakram3 still relevant
operatorMetadata: { | ||
OR: [ | ||
{ nodeOperationalStatus_isNull: true } | ||
{ nodeOperationalStatus: { isTypeOf_eq: "NodeOperationalStatusNormal" } } | ||
] | ||
} |
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.
Same comment here as with the query in distribution node
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.
Addressed
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'm suggesting to make multiple messages rather than a single one. Feels like a better design, but this will require a bit of refactoring here and in the storage-squid mappings.
const leadKey = await this.getDistributorLeadKey() | ||
|
||
let operationalStatus: INodeOperationalStatusMetadata = {} | ||
switch (statusType) { |
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.
It makes more sense to make it required, the command name doesn't imply what the default value should be.
|
||
message SetNodeOperationalStatus { | ||
optional NodeOperationalStatusMetadata operational_status = 1; // Node's operational status to set | ||
optional string worker_id = 2; // Storage/Distribution Worker ID |
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 would argue only the bucket_id
is strictly necessary in the message.
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.
Correct for storage nodes, but for distributor nodes we also need to know about the worker_id
, since a bucket can be assigned to multiple operators?
bucketId: flags.bucketId({ | ||
required: true, | ||
}), | ||
workerId: flags.integer({ |
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 suggested that worker id is not needed in metadata. If we agree on that, then this workerId can be dropped.
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 see #4793 (comment)
} | ||
|
||
// Node's Operational status to set | ||
optional OperationalStatus status = 1; |
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 would go further and suggest that we should probably have multiple messages, corresponding with the options in the commands for setting the metadata.
message NodeOperationalStatusNormal {
optional string rationale = 1;
required string bucketId = 2;
}
message NodeOperationalStatusNoService {
optional string rationale = 1;
required string bucketId = 2;
}
NodeOperationalStatusNoServiceFrom {
optional string rationale = 1;
required string from = 2; // date
required string bucketId = 3;
}
NodeOperationalStatusNoServiceUntil {
optional string rationale = 1;
optional string from = 2 // date
required string until = 3; // date
required string bucketId = 4;
}
Doing this I think will help address a couple issues raised in other places in the review as well as simplifying implementation in the commands and squid mappings I presume.
type: 'datepicker', | ||
name: 'result', | ||
clearable: true, | ||
default: new Date('2017-09-28 17:36:05').toISOString(), |
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.
Tried the date picker, works really nicely in the terminal!
Perhaps a more reasonable default would be the current date new Date().toISOString()
, so less fiddling with inital year and month for the user.
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.
Done
published protobuf and joystream/js packages (for joystream/js I bumped the dependency on protobuf package) |
Addresses #4765
operator:set-metadata
&leader:set-node-operational-status
CLI commandsWIP: Updating Storage/Distribution related integration testsImproving Storage/Distribution related integration tests #4815