-
Notifications
You must be signed in to change notification settings - Fork 458
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
api-refactor: SVID API service definition #1533
api-refactor: SVID API service definition #1533
Conversation
// used if unset. The TTL is advisory only. The actual lifetime of the | ||
// X509-SVID may be lower depending on the remaining lifetime of the active | ||
// SPIRE Server CA. | ||
int32 ttl = 3; |
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 field number should be 2?
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 believe that svid.pb.go should be re-generated and updated to reflect the field number change.
Yes, yes it should :) Thanks. |
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 is the definition for the SVID API in the Server API refactor. This is not set in stone and some decisions actively in discussion are sure to change this, albeit superficially. I'm introducing this now so we can kick off development. This API was a good candidate since it was 1) very small and focused, 2) not likely to change much as the API solidifies, 3) uses a broad range of SPIRE internals to do its job. Developing this API will help establish patterns and practices that should be applicable to other API development. Signed-off-by: Andrew Harding <andrew.harding@hpe.com>
cbf627f
to
28df360
Compare
This is the definition for the SVID API in the Server API refactor. This is not set in stone and some decisions actively in discussion are sure to change this, albeit superficially.
I'm introducing this now so we can kick off development. This API was a good candidate since it was:
Developing this API will help establish patterns and practices that should be applicable to other API development.