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

Nomad UI cannot browse /alloc volume #7799

Closed
gmichalec-pandora opened this issue Apr 24, 2020 · 6 comments
Closed

Nomad UI cannot browse /alloc volume #7799

gmichalec-pandora opened this issue Apr 24, 2020 · 6 comments

Comments

@gmichalec-pandora
Copy link

Nomad version

0.11.1+ent

Operating system and Environment details

Debian Stretch

Issue

The nomad UI currently has no way to browse files in the shared /alloc volume. Unless I am missing it, we can browse files related to a particular task by clicking the allocation -> task -> files, but there is no UI path that will display files in the /alloc volume, as shown in the following cli command:

Mode        Size     Modified Time              Name
drwxrwxrwx  4.0 KiB  2020-04-24T13:04:14-07:00  alloc/
drwxrwxrwx  4.0 KiB  2020-04-24T13:04:21-07:00  savagecloud-monitoring/

In my experience, users are more likely to make use of the /alloc shared volume than the local task directory, so being able to easily browse and view files in that path would greatly improve the UX

The nomad UI has improved by leaps and bounds - great effort guys! I believe this is the last major feature we would need to migrate our users to using nomad UI vs the 3rd party hashi-ui tool.

@DingoEatingFuzz
Copy link
Contributor

Thank you for this report! This is a pretty glaring oversight that emerged from our decision to show the filesystem at the task level rather than the allocation level.

We definitely need to address this.

@gmichalec-pandora
Copy link
Author

Thank you! I'll also add, though this is purely anecdotal, several of our users had trouble finding the logs/files UIs. It seems that the putting them at the task level was not easily discoverable - though this may be primarily due to our users being accustomed to using hashi-ui, which does roll up the logs/files at the alloc level. I can see arguments for both approaches.

backspace added a commit that referenced this issue Jun 1, 2020
This partially addresses #7799.

Task state filesystems are contained within a subdirectory of their
parent allocation, so almost everything that existed for browsing task
state filesystems was applicable to browsing allocations, just without
the task name prepended to the path. I aimed to push this differential
handling into as few contained places as possible.

The tests also have significant overlap, so this includes an extracted
behavior to run the same tests for allocations and task states.
backspace added a commit that referenced this issue Jun 1, 2020
This partially addresses #7799.

Task state filesystems are contained within a subdirectory of their
parent allocation, so almost everything that existed for browsing task
state filesystems was applicable to browsing allocations, just without
the task name prepended to the path. I aimed to push this differential
handling into as few contained places as possible.

The tests also have significant overlap, so this includes an extracted
behavior to run the same tests for allocations and task states.
@backspace
Copy link
Contributor

Hey, 0.11.3 is released and it includes a browser for allocation filesystems! Thanks for the feature request and let us know how it works for you. 🥳

@gmichalec-pandora
Copy link
Author

Sorry for not getting back to you sooner - this works great! Thanks!

@backspace
Copy link
Contributor

No problem, thanks for the update! I‘m glad it’s suitable 😀

@github-actions
Copy link

github-actions bot commented Nov 6, 2022

I'm going to lock this issue because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 6, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants