-
Notifications
You must be signed in to change notification settings - Fork 7
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
Automount: neuro run --volume=ALL #980
Conversation
Please merge #977, rebase against the master, and ask for review again. |
Lately, when I was having multiple consequent PRs one depending on another, I always added the notification "WARNING: depends on #977" to the description of all non-ready-for-review PRs. Sorry for misunderstanding. From now on, I will not open a non-WIP PRs if they are not ready to be compared against master. |
Codecov Report
@@ Coverage Diff @@
## master #980 +/- ##
========================================
Coverage ? 92.5%
========================================
Files ? 37
Lines ? 4283
Branches ? 647
========================================
Hits ? 3962
Misses ? 213
Partials ? 108
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## master #980 +/- ##
==========================================
+ Coverage 87.3% 92.16% +4.85%
==========================================
Files 37 37
Lines 4568 4592 +24
Branches 681 686 +5
==========================================
+ Hits 3988 4232 +244
+ Misses 452 245 -207
+ Partials 128 115 -13
Continue to review full report at Codecov.
|
@pytest.mark.parametrize( | ||
"env_var", ["NP_STORAGE_ROOT_MOUNTPOINT", "NP_STORAGE_ROOT_MOUNTPOINT=value"] | ||
) | ||
def test_build_env_reserved_env_var_conflict_passed_as_parameter(env_var: str) -> None: |
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.
apart from these two tests, build_env
is not covered
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.
should we properly cover it then?
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.
sure. but not in this PR. Issue: #995
@@ -877,6 +873,55 @@ def format_fail(job: str, reason: Exception) -> str: | |||
return job | |||
|
|||
|
|||
async def _build_volumes( | |||
root: Root, input_volumes: Sequence[str], env_dict: Dict[str, str] |
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.
are input_volumes
unique?
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.
no, it's direct user input.
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.
should we handle edge cases such as same volumes etc? (prob out of scope)
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.
looking at the code, I can say that this case is handled properly: the result collection volumes
is of type Set
(but in order to reduce number of loop iterations, I changed input array to the type of Set
as well).
However, this is a good case indeed, neuro run --volume=ALL --volume=<custom>
, so since --volume=ALL
already mounts all possible volumes, I changed the code to forbid this option together with any other option -- thank you for pointing this out!
neuromation/cli/job.py
Outdated
) | ||
for perm in available: | ||
root_dir = ( | ||
perm.uri.host if perm.uri.host != root.username else "home" |
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.
not sure the home
link is what we want really. I'd rather have a separate link (an additional mount) instead of renaming the owners home dir. also, we could easily introduce an environment var to address this (e.g. $HOME
).
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.
In this PR, we made this decision to mount user home directory to /var/storage/home
not to /var/storage/username
in order to be compliant with --volume=HOME
in order not to confuse users. I don't think we need to have both mounts.
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.
In addition, in a scheme storage://username/path/to/dir
, we do not use username
as a location of user's home directory, technically, in NFS it can be anywhere (for example, not in /username
but /home/username
), so I think it's good practice to mount user dir to /var/storage/home
.
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 think this is wrong as this is not corresponding to what neuro ls storage:/
returns.
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.
this is question of taste, let's ask our users (cc @mariyadavydova).
Currently:
--volume=HOME
:storage://alice/
->/var/storage/home/
We need to implement --volume=ALL
. Suppose, alice
is using this command. There are 2 options:
- replace user's name with
home
in order to be consistent with--volume=HOME
(and not cause surprises for our users):
storage://alice/dir1
->/var/storage/home/dir1
storage://bob/dir2
->/var/storage/bob/dir2
- as @dalazx proposes, do not change anything and thus simplify algorithm for
--volume=ALL
:
storage://alice/dir1
->/var/storage/alice/dir1
storage://bob/dir2
->/var/storage/bob/dir2
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.
@ayushkovskiy This is a very good idea! We can introduce something like this:
> neuro storage protect storage:project/data
> neuro run ... --volume storage:project/data:/var/storage/data:rw ...
Warning: You are trying to mount storage:project/data with read-write access,
while this directory is marked as protected. Access us downgraded to read-only.
To get read-write access for this directory please remove the protection mode with
neuro storage protect --remove storage:project/data
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 too complicated in my opinion.
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 think it should be an option for "serious teams, concerned about data security". I mean, in most cases you can simply watch out your commands and use proper access modifiers. But if you are really concerned, you may additionally use such an option as a safety net. This may be especially relevant for teams, sharing the same data.
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 agree we should print a warning for all rw
volumes
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.
closes #974