Brett Smith [Tue, 21 Apr 2015 20:48:42 +0000 (16:48 -0400)]
5490: Require exact matches in API server's default job reuse filters.
The previous default filters would reuse jobs that used any Docker
image with the matching name, and/or Arvados SDK version since the
named commit. User feedback indicates this is surprising, and they
would prefer to have behavior more like the handling around
script_version: only reuse jobs that have the latest version of a
symbolic name, or the exact specified hash.
Brett Smith [Tue, 21 Apr 2015 15:23:19 +0000 (11:23 -0400)]
5490: Test API server handling of git hash-like branch names.
If you have a branch that looks like a commit hash, different git subcommands do different things. After extended discussion on IRC, we've decided we'd like the rules to be:
* If a 40-character hex string references a commit, resolve it to that
commit.
* In other cases of ambiguity, prefer branch names over short commit
hashes.
Fortunately, this corresponds to the behavior of `git rev-list` and
our existing implementation. This commit codifies our desired
behavior with tests.
This is an affordance to help users find logs after they're removed
from the API server's logs table. The display is not very great.
We're punting improvements until Workbench generally has better
capabilities to display large logs.
The layout change necessitated updates to the anonymous access tests.
While I was in there, I strengthened the assertions by putting
assertions that check a particular element has loaded before asserting
the nonexistence of other elements. This revealed the JavaScript
issue mentioned in the new comment: the old version of the test was
doing a single `assert_no_text` after clicking a job's log tab, which
only confirmed that we navigated away. We already test that the log
tab exists and is not disabled in this case, so I consider that
sufficient for now.
Brett Smith [Thu, 23 Apr 2015 21:52:27 +0000 (17:52 -0400)]
run_test_server doesn't assume ARVADOS_API_TOKEN is set.
This makes it slightly more feasible to run this script (and by
extension tests for individual components like Workbench) outside
run-tests.sh. No issue #.
5780: Display message in chooser popup if one is provided. Use this to show a message in sharing popup
explaining to user that only those users or groups that the user is allowed to access are displayed.
* Leave -volumes (and accept comma-separated dir lists) for backward
compatibility.
* Detect read-only filesystems when using /proc/mounts to discover
Keep volumes.
* VolumeManagers know whether volumes are writable, so it's not
necessary to wait in a serialize queue just to find out a volume
isn't writable.
* Simplify RRVolumeManager: use atomic.AddUint32() instead of channels
and goroutines.
* -serialize (like -readonly) now affects only the volumes that come
after it in the argument list (and automatically discovered
volumes). This makes it possible to have a mix of serialized and
non-serialized volumes.
* Fix some test cases that just skipped the test (instead of failing)
when encountering an error during test setup.
* Move MockVolume code from volume.go to volume_test.go.
* Clean up some over-indented code blocks, see
https://github.com/golang/go/wiki/CodeReviewComments#indent-error-flow
* Remove some stating-the-obvious/redundant comments and duplicate log
messages.
Brett Smith [Tue, 14 Apr 2015 17:13:29 +0000 (13:13 -0400)]
5717: crunch-job uses fewer slots when few tasks at this level.
When crunch-job begins tasks at a new level, it looks at the number of
tasks scheduled for that level. If that's smaller than the maximum
number of slots available, then it only considers slots "free" up to
the number of tasks scheduled, or the number of nodes available,
whichever is greater.
This change lets Crunch scale whole-node resources like RAM more
effectively. This may not be desired if a level starts with a small
number of tasks queued, but later schedules more and wants maximum
parallelization, but that's uncommon enough that this seems like net
win. Previously, Crunch could overallocate RAM in this scenario,
which seems worse.
Brett Smith [Mon, 13 Apr 2015 20:48:16 +0000 (16:48 -0400)]
5714: Avoid Node Manager race conditions around stop_if_no_cloud_node.
Checking .is_alive() seems to always lead to race conditions.
Instead, have CloudNodeSetupActor.stop_if_no_cloud_node() return True
if it's going to stop, else False. Have NodeManagerDaemonActor
respect this return value consistently.
projects / arvados.git / log