-
Notifications
You must be signed in to change notification settings - Fork 813
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
Implement converters between the GameServerAllocation API and allocation.proto #1117
Conversation
Build Failed 😱 Build Id: 36d4daa2-3b0e-45da-b6b1-ecc27c9db2ff To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Build Succeeded 👏 Build Id: d75fa1c3-14e9-4061-8855-99e812b503b4 The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
pkg/allocation/libs/converter.go
Outdated
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | ||
) | ||
|
||
// ConvertAllocationRequestV1Alpha1ToGSAV1 converts AllocationRequest to GameServerAllocation V1 (GSA) |
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 GSA v1 the "canonical" form? When we introduce v1beta1 or v1 for the allocation api how much more conversion code will we need to add?
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.
If we diverge to multiple versions of GSA and allocation.proto, there may be multiple conversions. However, ideally the conversions will always happen to the latest GSA and we handle compatibility at this layer. In that case there should be an internal version of GSA.
pkg/allocation/libs/converter.go
Outdated
// limitations under the License. | ||
|
||
// Package converters includes API concersions between GameServerAllocation API and the Allocation proto APIs | ||
package converters |
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 looks like this was all done by hand. But the fields in the proto and the k8s api look very similar. Is there a reason that we don't auto-generate the service definition from the api spec (to reduce the amount of manual conversion 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.
I looked into proteus. There are some issues generating proto from golang package due to old packages and mismatches, but it seems to be eventually doable. Now I am thinking how much value do we get by reusing Spec and Status. Here are the pros and cons for not auto generating part of API from GSA:
pros:
- Separating external facing APIs and internal APIs for agones-allocator. The external API is allocation.proto and the internal API is GSA. Internal API may change, but the external API should not change after a stable release.
- The allocation.proto fields will follow best practices for REST and gRPC API design and GSA will follow the k8s API design. So for example in the case of status, I am planning to drop states (Proposal: Allocator service to return 400+ http status for failure #1040) for contention and unallocated and returning the expected gRPC errors. There are also field names that are different between the two e.g. preferredGameServerSelectors vs preferred.
- proto generation and keeping dependency in sync with proteus seems to be a hassle (I still haven't got it working)
Cons:
- There are more maintenance e.g. writing more code for conversion layer and making sure the API is in sync.
I am inclined to keep the APIs as is partly because of the benefits I explain which I feel outweights the disadvantages, and partly because I am biased at this stage :)
Let me know if you have a strong opinion on generating the proto.
Build Failed 😱 Build Id: 23f4668d-17ea-40a2-a2fe-ecedc1537719 To get permission to view the Cloud Build view, join the agones-discuss Google Group. |
Build Succeeded 👏 Build Id: e77f53df-4d81-49fa-bee6-c6c65cf6c4cf The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
Build Succeeded 👏 Build Id: 0ffa635a-e1ce-4160-8839-73dfaf18486c The following development artifacts have been built, and will exist for the next 30 days:
A preview of the website (the last 30 builds are retained): To install this version:
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pooneh-m, roberthbailey The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Allocation.proto will be the external facing API for agones-allocator service. To use the allocation logic, the service needs to converts between external API (e.g allocation.proto) and internal API (e.g. GameServerAllocation).
This change includes: