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

Introduce TransferCommitment API #410

Merged
merged 42 commits into from Mar 21, 2024
Merged

Introduce TransferCommitment API #410

merged 42 commits into from Mar 21, 2024

Conversation

VoigtS
Copy link
Member

@VoigtS VoigtS commented Mar 5, 2024

productionChecklist:

  • I updated the documentation to describe the semantical or interface changes I introduced.

This PR introduces commitment transfers from a source to a target project.
Two API's will be implemented:

  • start-transfer: Either marks a commitment as transferrable or splits the commitment into two parts where the provided amount will be the indicator for the transferrable commitment
  • transfer-commitment: Where the actual commitment transfer from a source to a target AZ_RESOURCE_ID will be executed.

@VoigtS VoigtS changed the title Add Skeleton transferCommitment endpoint Introduce TransferCommitment API Mar 5, 2024
@coveralls
Copy link

coveralls commented Mar 5, 2024

Coverage Status

coverage: 80.818% (-0.5%) from 81.277%
when pulling 7765102 on transfer
into 256a835 on master.

@VoigtS VoigtS marked this pull request as ready for review March 11, 2024 11:31
docs/users/api-spec-resources.md Outdated Show resolved Hide resolved
docs/users/api-spec-resources.md Outdated Show resolved Hide resolved
docs/users/api-spec-resources.md Outdated Show resolved Hide resolved
docs/users/api-spec-resources.md Outdated Show resolved Hide resolved
internal/api/commitment.go Outdated Show resolved Hide resolved
internal/api/commitment_test.go Outdated Show resolved Hide resolved
internal/api/utils.go Outdated Show resolved Hide resolved
Copy link
Contributor

@majewsky majewsky left a comment

Choose a reason for hiding this comment

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

Please do not be disheartened by the number of remarks. You did a good job getting accustomed to the existing code structure and following house conventions. But there is some work left to do, both in the stylistic and functional departments:

docs/users/api-spec-resources.md Outdated Show resolved Hide resolved
internal/api/api_test.go Outdated Show resolved Hide resolved
internal/api/commitment.go Outdated Show resolved Hide resolved
internal/api/commitment.go Outdated Show resolved Hide resolved
internal/api/commitment.go Outdated Show resolved Hide resolved
internal/api/commitment_test.go Outdated Show resolved Hide resolved
internal/api/commitment_test.go Show resolved Hide resolved
internal/api/commitment_test.go Show resolved Hide resolved
internal/api/core.go Outdated Show resolved Hide resolved
internal/api/utils.go Outdated Show resolved Hide resolved
VoigtS and others added 14 commits March 15, 2024 13:26
Documentation: Fix grammatical indistinctness.

Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Nounify variable names of SQL queries.

Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Token check: Remove error return message. Already handled by token.Require function.

Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Rename: splitCommitment function to buildSplitCommitment.

Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Commitment test: Update parameter from snake case to camel case.

Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Tests: Negative tests now check the body content
Simplify commitment transfer. Utilize ORM.

Co-authored-by: Stefan Majewsky <stefan.majewsky@sap.com>
Update transfer commitment test with split commitment
@VoigtS
Copy link
Member Author

VoigtS commented Mar 15, 2024

Reminder: Check on Monday - Previous OLTP implementation had a bug in the transferred commitment.
Only the return value contained the Transferstatus and Token of the splitted commitment transferCommitment.
However, the values were not mirrored in the database.

The ORM implementation now takes this into account and saves the values in the database. A additional test case was added that tests the transfer of a splitted commitment.


// find commitment by transfer_token
var dbCommitment db.ProjectCommitment
err := p.DB.SelectOne(&dbCommitment, getCommitmentWithMatchingTransferTokenQuery, transferToken)
Copy link
Contributor

Choose a reason for hiding this comment

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

Should also match on ID, as defense in depth.

Copy link
Member Author

Choose a reason for hiding this comment

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

The query now respects the commitment ID (read out of the URL)


// get target AZ_RESOURCE_ID
var targetResourceID db.ProjectAZResourceID
err = p.DB.QueryRow(findTargetAZResourceIDBySourceIDQuery, targetProject.ID, dbCommitment.AZResourceID).Scan(&targetResourceID)
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks like it does not match on service type and resource name. How is the commitment matched to the correct service and resource on the receiving side?

The tests can plausibly work "by accident" because they all use first/capacity which is the alphabetically first service/resource.

Copy link
Member Author

Choose a reason for hiding this comment

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

You are absolutely correct. I fixed this with a Common Table Expression that queries the service type, resource name and AZ from the source commitment.
Additionally I changed the tests to use the service "second". In the old implementation this caused the selected resource_az_id to be from the service "first". It now points to the correct service.

Caused: on multipyle services or resources the first entry was selected and not the values the source commitments holds
@VoigtS
Copy link
Member Author

VoigtS commented Mar 19, 2024

Fixed: Movement of the transfer token from queryString into the request header.

@VoigtS VoigtS requested a review from majewsky March 19, 2024 15:41
Respects the movement of the transfer token as queryString into the header
@majewsky majewsky merged commit f00f549 into master Mar 21, 2024
7 checks passed
@majewsky majewsky deleted the transfer branch March 21, 2024 12:31
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.

None yet

4 participants