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

improve State and API marshaling and add keystore status support #2

Merged
merged 1 commit into from
Mar 8, 2023

Conversation

aead
Copy link
Member

@aead aead commented Mar 6, 2023

This commit improves the State and API JSON
marshaling by decoupling it from the struct
representation and adding additional checks for
invalid data.

Further, this commit adds support for the keystore status information exposed by minio/kes#339

@aead aead force-pushed the status branch 4 times, most recently from 0d9190d to 879e1c8 Compare March 6, 2023 16:34
This commit improves the `State` and `API` JSON
marshaling by decoupling it from the struct
representation and adding additional checks for
invalid data.

Further, this commit adds support for the keystore
status information exposed by minio/kes#339

Signed-off-by: Andreas Auernhammer <hi@aead.dev>
Copy link

@Praveenrajmani Praveenrajmani left a comment

Choose a reason for hiding this comment

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

Q: Why do we need this translation in marshaling and unmarshaling? Can we infer from the "original" struct?

Comment on lines +36 to +43
UpTime time.Duration `json:"uptime,omitempty"`
CPUs int `json:"num_cpu,omitempty"`
UsableCPUs int `json:"num_cpu_used,omitempty"`
HeapAlloc uint64 `json:"mem_heap_used,omitempty"`
StackAlloc uint64 `json:"mem_stack_used,omitempty"`
KeyStoreLatency time.Duration `json:"keystore_latency,omitempty"`
KeyStoreUnreachable bool `json:"keystore_unreachable,omitempty"`
KeyStoreUnavailable bool `json:"keystore_unavailable,omitempty"`

Choose a reason for hiding this comment

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

can we keep camelCased JSON tags for go styling reasons?

Comment on lines +75 to +82
UpTime time.Duration `json:"uptime"`
CPUs int `json:"num_cpu"`
UsableCPUs int `json:"num_cpu_used"`
HeapAlloc uint64 `json:"mem_heap_used"`
StackAlloc uint64 `json:"mem_stack_used"`
KeyStoreLatency time.Duration `json:"keystore_latency"`
KeyStoreUnreachable bool `json:"keystore_unreachable"`
KeyStoreUnavailable bool `json:"keystore_unavailable"`

Choose a reason for hiding this comment

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

can we keep camelCased JSON tags for go styling reasons?

Copy link

@Praveenrajmani Praveenrajmani Mar 7, 2023

Choose a reason for hiding this comment

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

is this because we already used snake cased tags and we need to follow this for backward compatibility reasons?

Copy link
Member Author

Choose a reason for hiding this comment

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

Mainly yes, we need to preserve compatibility. Also, snake vs. camel case conventions aren't strict for JSON - esp. since these fields are part of the KES server JSON API - which may not only be consumed by Go.

For Go identifiers we should follow camel case convention as long as possible 👍

@aead aead requested a review from Praveenrajmani March 8, 2023 08:08
@aead aead merged commit 8024fa5 into main Mar 8, 2023
@aead aead deleted the status branch March 8, 2023 10:08
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