-
Notifications
You must be signed in to change notification settings - Fork 2
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
feat: support for search reprovisioning #392
Conversation
Pull Request Test Coverage Report for Build 11163620994Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
1bdbd6f
to
f0100b2
Compare
You can access the deployment of this PR at https://renku-ci-ds-392.dev.renku.ch |
d4fa5aa
to
7a35a65
Compare
7a35a65
to
6e4aa7c
Compare
d69d7b8
to
66a3610
Compare
66a3610
to
a028799
Compare
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.
Thanks this looks really good Mohammad. I have a few questions and requests for changes. For some of the questions it may be easier to have a live discussion - but you tell me what you prefer.
This table is used to make sure that only one instance of reprovisioning is run at any given time. | ||
It gets updated with the reprovisioning progress. |
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.
suggestion: I think we should add a constraint to this table that makes so that either:
- it can only ever contain one row
- OR it can contain a history of all reprovisionings but we add an
active
boolean column and add a constraint so that only 1 row can have active set to true at any time.
i.e. some way so that even if we mess things up in our code we can only have 1 reprovisioning happening at a time.
async with session_maker() as session, session.begin(): | ||
start_event = make_event( | ||
message_type="reprovisioning.started", payload=v2.ReprovisioningStarted(id=str(reprovisioning.id)) | ||
) | ||
await event_repo.store_event(session, start_event) |
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.
suggestion: I know we check if a reprovisioning is already going on in the db.py. But I think it is safer/nicer to not even send the reprovisioning.started
event if another reprovisioning is underway. So the first thing we check inside this db transaction should be whether another reprovisioning is already in progress. And if it is then fail/do nothing. We should do this in addition with a constraint on the table in the DB.
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.
We check if a reprovisioning is active, in the blueprint and before calling this function. So, the reprovisioning.started
message isn't sent twice.
I'll add the DB constraint in the follow up PR.
def delete(self) -> BlueprintFactoryResponse: | ||
"""Stop reprovisioning (if any).""" |
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.
question: Do we really want this at all? Because if you start a reprovisioning but then stop it you leave the event queue in a weird inconsistent state. So maybe once you start a reprovisioning you have to wait for it to finish or error out.
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.
Some 2 cents: while a delete
action may not be desirable, there should be a way to force a reprovisioning to be marked as errored. You cannot always ensure that a job will report back it has errored, so an admin needs to be able to mark it that way (and attempt a new one).
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.
Yeah the DELETE endpoint to stop a reprovisioning will stay.
id: Mapped[ULID] = mapped_column("id", ULIDType, primary_key=True, default_factory=lambda: str(ULID()), init=False) | ||
start_date: Mapped[datetime] = mapped_column("start_date", DateTime(timezone=True), nullable=False) |
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.
question: How do we handle errors during reprovisioning? And we have 2 kind here:
- Errors that fully crash the whole reprovisioning process
- Errors that may result from trying to reprovision a specific entity only
At least for no 1 we should save something in the database and report it back to the admin. For no 2 the question is whether we want to keep going if we encounter errors with some entities or do we fully stop?
And related to this is another question. What do we do if we encounter an error? Should we try to delete the / cleanup the events that were added so that we can effectively rollback to the pre-reprovisioining request state?
a8d9d6f
to
eedd5b5
Compare
95583bc
to
2868fe3
Compare
2868fe3
to
9b5ec4c
Compare
9b5ec4c
to
4a2c768
Compare
4a2c768
to
21316e2
Compare
21316e2
to
eb521da
Compare
eb521da
to
d545020
Compare
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.
That is great just one minor thing I noticed in the apispec.
Tearing down the temporary RenkuLab deplyoment for this PR. |
Adds a Sanic background task that reads data from the database and sends them as events.
Search reprovisioning.
/deploy