-
Notifications
You must be signed in to change notification settings - Fork 31
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
models: add Interactive Session model #90
models: add Interactive Session model #90
Conversation
4fb1c3e
to
31c0c65
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.
Looks good :) I've added a couple of comments regarding naming and relationships which shouldn't be creating much trouble in your current implementation, once we decide on them, you can create the Alembic recipe.
reana_db/models.py
Outdated
__tablename__ = "user_workflow_session" | ||
__table_args__ = {"schema": "__reana"} | ||
|
||
user_id = Column(UUIDType, ForeignKey("__reana.user_.id_"), 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.
Do we need to add the user here? I rather see this table as WorkflowSession
or WorkflowInteractiveSession
and the relation to User
to be simply backtracked from InteractiveSession
through owner_id
(I see ternary relationship was mentioned in the original issue, but I have second thoughts).
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's a good solution IMO. @tiborsimko , what do you think?
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.
Yes, for this sprint and for MVP, it seems perfectly OK indeed.
(However, we may need to refactor this later, when we shall be addressing user group and access rights. Example: currently, a Workflow
row has an owner_id
, but in reality there can be several people associated with a workflow: one main owner, 2-3 collaborators having some R/W rights e.g. to rerun it, a convener having R/O rights to see the results, etc. Some collaborators could run different notebooks on the same workspace, not being owners strictly speaking... These kinds of considerations can naturally wait for later; however it is good to have a future outlook with a flexible "user-workflow-session-role" structure in mind to see where we shall be heading later.)
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.
@tiborsimko, should we create an issue from your comment? Or this is something to bear in mind?
jupyter = 0 | ||
|
||
|
||
class InteractiveSession(Base, Timestamp): |
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 are missing the InteractiveSessionResource
table (like WorkflowResource
), we will need it to account resource usage in InteractiveSessions (more here).
For now, we should measure just CPU usage, not disk usage since now the workspace is the same as the workflow and it is already accounted (which would change if we go for https://github.com/reanahub/reana-db/pull/90/files#r501548133). Can you remember to open an issue for this, "accounting for InteractiveSessions
CPU usage" once we merge this?
69b73dc
to
38845c8
Compare
1fa73aa
to
359fa3c
Compare
Minor: there's a typo in the last commit title. |
b6baafd
to
a560101
Compare
a560101
to
30c4863
Compare
closes #89