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.

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

docs: update build_stage examples #12495

Closed
wants to merge 2 commits into from

Conversation

tldahlgren
Copy link
Contributor

@tldahlgren tldahlgren commented Aug 21, 2019

See #12072

Update more build_stage examples due to the potential impact of spack clean should the old example paths be used.

@mwkrentel
Copy link
Member

@tldahlgren @scheibelp @tgamblin
IMO this patch and #12492 misunderstand the problem here.

The problem is not a better error message or better documentation.
The problem is that you reduced the options for build_stage to
ONE option and that option DOES NOT WORK.

build_stage:
- $tempdir/spack-stage

Here, you expect $tempdir to have permissins like 1777 and so you
can create new directories there. But /tmp/spack-stage does not
have mode 1777. It's owned by another user. This has become a race
condition where it works for the first person to run spack on this
machine and then fails for the other N-1.

You need to restructure the temp dirs so that each user has their own
copy of spack-stage that is writeable for that user.

@tldahlgren
Copy link
Contributor Author

@tldahlgren @scheibelp @tgamblin
IMO this patch and #12492 misunderstand the problem here.

The problem is not a better error message or better documentation.
The problem is that you reduced the options for build_stage to
ONE option and that option DOES NOT WORK.

build_stage:
- $tempdir/spack-stage

The idea was there was a single "default" value which the user could override. (I was under the impression that was often the case).

Here, you expect $tempdir to have permissins like 1777 and so you
can create new directories there. But /tmp/spack-stage does not
have mode 1777. It's owned by another user. This has become a race
condition where it works for the first person to run spack on this
machine and then fails for the other N-1.

You need to restructure the temp dirs so that each user has their own
copy of spack-stage that is writeable for that user.

There are systems that automatically add $user to $tempdir. (That is clearly not the case in your environment but they do exist.) In order to avoid the potential for multiple $user nodes in the path, staging is supposed to be appending $user to the first accessible build_stage path when establishing the stage root directory. Unfortunately, I now see I missed the case where the path exists but the user cannot access it.

@tldahlgren
Copy link
Contributor Author

Closing since, after much internal discussion, the build_stage path is going to be re-worked.

@tldahlgren tldahlgren added build General build capability documentation labels Aug 26, 2019
@tldahlgren tldahlgren deleted the docs/update-build-stage branch August 29, 2019 21:28
@tldahlgren tldahlgren self-assigned this Oct 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
build General build capability documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants