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.

Sign up for GitHub

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

Jump to bottom

Investigate making tableOperations.online() more strict with table state checks #4132

Closed
DomGarguilo opened this issue Jan 5, 2024 · 3 comments · Fixed by #4165
Closed

Investigate making tableOperations.online() more strict with table state checks #4132

DomGarguilo opened this issue Jan 5, 2024 · 3 comments · Fixed by #4165
Assignees
@kevinrr888
Milestone
2.1.3

Comments

@DomGarguilo
Copy link
Member

DomGarguilo commented Jan 5, 2024 •
edited
Loading

There was some discussion (below) about investigating if there should be more strict checks in regards to table state when using tableOperations().online(). Not sure the extent of the current checks, but it at least allows a table to be onlined when it is in a NEW table state which is questionable.

Does the following sound correct? Want to make sure I understand these changes.

  • Without these changes the table would be in the new state, so client.tableOperations().isOnline(destTable) would have returned false.
  • The call to client.tableOperations().online(destTable, true) just kinda fix things for the rest of the test.

If that is true, it makes me wonder if the call client.tableOperations().online(destTable, true) should be a bit more strict about what table states it will transition.

Originally posted by @keith-turner in #4115 (comment)
@kevinrr888
Copy link
Member

I would like to work on this

kevinrr888 added a commit to kevinrr888/accumulo that referenced this issue Jan 17, 2024
@kevinrr888
Stricter checks before transitioning table state
4d01ec8 
Closes apache#4132
Prior to these changes, users were able to manually transition a table from the NEW state to another state. More specifically, calls to TableOperations.online() and TableOperations.offline() when the table was in the NEW state were acceptable. Users should not be able to transition a table from the NEW state as this should only be done by the system upon successfully creating/cloning/importing the table.
Changes:
- Added new param expectedCurrStates to TableManager.transitionTableState()
- Users can now only manually change a table from [ONLINE/OFFLINE]->[ONLINE/OFFLINE] (FateServiceHandler)
- Added field expectedCurrStates to ChangeTableState
- Table clones, creations, and imports now explicitly expect the current state before completion to be NEW (FinishCloneTable, FinishCreateTable, FinishImportTable)
- Table deletions now explicitly expect the current state before deletion to be only ONLINE or OFFLINE (DeleteTable)
@kevinrr888 kevinrr888 mentioned this issue Jan 17, 2024
Merged
@kevinrr888
Copy link
Member

I believe this issue can be closed now

@DomGarguilo DomGarguilo linked a pull request Jan 18, 2024 that will close this issue
Stricter checks before transitioning table state #4165
Merged
@DomGarguilo
Copy link
Member Author

Closing as completed via #4165

@ctubbsii ctubbsii modified the milestones: 3.1.0, 2.1.3 Jul 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@kevinrr888 kevinrr888

Labels
None yet
Projects
None yet
Milestone
2.1.3
Development

Successfully merging a pull request may close this issue.

Stricter checks before transitioning table state kevinrr888/accumulo
3 participants
@ctubbsii @kevinrr888 @DomGarguilo