Kickoff Project Manager Docs #1197
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,65 @@ | ||
| .. _project_manager: | ||
|
|
||
| Project Manager | ||
| =============== | ||
|
|
||
| Overview | ||
| -------- | ||
|
|
||
|
|
||
| Setup | ||
| ----- | ||
|
|
||
| For individual projects, there is no setup required. Anybody with the permissions | ||
| to submit jobs to your scheduler will also be able to use all of the launcher and | ||
| workflow tools of the Project Manager after updating to v4.1. In order for users | ||
| to collaborate together they will need a properly configured shared directory, | ||
| meeting :ref:`these minimum permissions <project_manager_shared_project_root>` | ||
|
|
||
|
|
||
| .. _project_manager_collaboration: | ||
|
|
||
| Collaboration | ||
| ------------- | ||
| Collaborative projects need properly configured directories to exist in, which may | ||
| vary on the types of collaboration you would like to enable. Like other actions in | ||
| Open OnDemand, it will operate as the logged in user and never exceed the UNIX | ||
| permissions of the directories and files it operates on. This means there are several | ||
| different approaches you may want to take depending on your file system's account and | ||
|
Contributor
Author
There was a problem hiding this comment. We should also put some thought into other approaches to file permissions and how those will cooperate with the PM. (I know some places use our Allowlist functionality, but is this an alternative to group-level management?) Basically we should be minimal with our required permissions in order to remain compatible with whatever strategies people are using, but advocate and pull examples from an OSC inspired format. (Even OSC doesn't currently have these permissions yet, but we should make sure they are comfortable implementing our recommended approach). |
||
| permission management approach. | ||
|
|
||
| .. _project_manager_shared_project_root: | ||
|
|
||
| Shared Project Root | ||
| ------------------- | ||
|
|
||
| The project manager provides the ``OOD_SHARED_PROJECT_ROOT`` environment variable to | ||
| help potential collaborators discover potential projects to import. While this is | ||
| not necessary for collaboration, it is a recommended step to make it easier to locate. | ||
| The ``OOD_SHARED_PROJECT_ROOT`` is a list of base locations for shared projects, allowing | ||
| you to add as many locations as you need for different types of users and projects. | ||
| The Project Manager will only allow users to import projects from locations that they | ||
| have access to, so there is no danger in adding paths that are not accessible to certain | ||
| users. | ||
|
|
||
| Because many centers use group-based permission schemes, the Project Manager expects that | ||
| each directory in ``OOD_SHARED_PROJECT_ROOT`` has a set of subdirectories with finer permissions, | ||
| and will only look for projects in these subdirectories. | ||
|
|
||
| For example, a center may have a shared project folder ``/fs/shared/projects``, and a series of subdirectories | ||
| ``/fs/shared/projects/developers``, ``/fs/shared/projects/staff``, ``/fs/shared/projects/students``. | ||
|
|
||
|
|
||
| In this example, they would set ``OOD_SHARED_PROJECT_ROOT=/fs/shared/projects``, allowing developers | ||
| to create collaborative projects like ``/fs/shared/projects/developers/project1``, which are then | ||
| easily accessible to others in the ``developers`` group (likewise for ``staff`` and ``students``). | ||
|
|
||
| While the Project Manager automates the permissions settings on project-specific folders, these can | ||
| never exceed the permissions of the ``SHARED_PROJECT_ROOT`` or any group-level subdirectory, so it | ||
| is important to ensure that your directory structure meets these minimum requirements. | ||
|
|
||
| #. Any directory in ``OOD_SHARED_PROJECT_ROOT`` and above must have at minimum ``r-x`` permissions | ||
| for all potential collaborators. | ||
|
|
||
| #. Any group directory directly below ``OOD_SHARED_PROJECT_ROOT`` should have ``rwx`` permissions | ||
| for the group | ||
|
Contributor
Author
There was a problem hiding this comment. In light of discussion, we will try to handle setbit and sticky bit automatically in the project root, as described in OSC/ondemand#4780 and OSC/ondemand#4781 |
||
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -161,3 +161,4 @@ js | |
| balancers | ||
| OpenTofu | ||
| Terraform | ||
| subdirectories | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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 realize that the 'types of collaboration' referenced here is a little nebulous, but here is what I had in mind.
Basically, we should support both 'read-only collaboration' (collaborators can view, copy, and execute files, allowing them to run any launchers and workflows) and 'full collaboration' (collaborators have identical permissions to project owner).
I envision certain centers being uncomfortable with 'full collaboration', and so they could configure their directories to never allow non-owning collaborators to edit files. I also envision some project owners wanting to restrict their collaborators from editing specific projects (or limit 'full collaboration' to individuals within their group), so this would be an option in the project settings.
For these reasons, I would say that we recommend centers create shared directories with full group permissions, giving individual project owners the ability to restrict projects to read-only if they wish. These permission restrictions would only affect the project root (not shared root or group folders), and so would not need additional involvement from an admin.