Project

General

Profile

Feature #11887

Make the remote shell's file operations robust

Added by anonym over 2 years ago. Updated over 2 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Test suite
Target version:
Start date:
10/25/2016
Due date:
% Done:

100%

Feature Branch:
test/11887-remote-shell-file-operations
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

I.e. don't depend on quoting hacks + echo + cat + IO redirection in the shell for file operations (which makes binary data ugly business). We already have a command type, currently call and spawn, which we could extend with read, write, append with different parameters like path and data (for writes only).


Related issues

Blocks Tails - Feature #11888: Improve the remote shell's performance by switching to a virtio channel In Progress 10/25/2016
Blocks Tails - Feature #12059: Improve Dogtail's performance Resolved 12/21/2016

Associated revisions

Revision 9fb70d9c (diff)
Added by anonym over 2 years ago

Revert back to serial link for the remote shell transport.

We are experiencing lockups with the virtio channel that will need
further investigation.

Refs: #11887, #11888

Revision ef5eb75f
Added by intrigeri over 2 years ago

Merge remote-tracking branch 'origin/test/11887-remote-shell-file-operations' into stable (Fix-committed: #11887).

History

#1 Updated by intrigeri over 2 years ago

  • Related to Feature #11888: Improve the remote shell's performance by switching to a virtio channel added

#2 Updated by anonym over 2 years ago

  • Status changed from Confirmed to In Progress
  • Target version changed from Tails_2.9.1 to Tails 2.10
  • % Done changed from 0 to 30
  • Feature Branch changed from test/remote-shell-file-operations to test/11887-remote-shell-file-operations

I dropped the virtio parts (#11888) for now since it's plagued by lockups, so we can proceed with getting this merged faster.

#3 Updated by anonym over 2 years ago

  • Related to deleted (Feature #11888: Improve the remote shell's performance by switching to a virtio channel)

#4 Updated by anonym over 2 years ago

  • Blocks Feature #11888: Improve the remote shell's performance by switching to a virtio channel added

#5 Updated by anonym over 2 years ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 30 to 50
  • QA Check changed from Dev Needed to Ready for QA

Jenkin's look good. Please review'n'merge!

#6 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to anonym
  • Target version changed from Tails 2.10 to Tails_2.12
  • QA Check changed from Ready for QA to Dev Needed

The branch hasn't built successfully in Jenkins since a week (and actually was failing since 3 days when this ticket was set as Ready for QA), and it has a merge conflict with current devel.

Also, it's based on devel and wasn't ready in time for the 2.10 freeze, so I guess it's a candidate for 2.12 (unless it can actually be merged into current testing, in which case please set its base branch to something else than devel?).

#7 Updated by anonym over 2 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Dev Needed to Ready for QA

intrigeri wrote:

The branch hasn't built successfully in Jenkins since a week (and actually was failing since 3 days when this ticket was set as Ready for QA), and it has a merge conflict with current devel.

Sorry! I had failed to click "Submit" in the tab where I had written the above comment for a few days. Apparently things already had gone bad when I noticed this and pressed the button. Next time I'll make sure to look at Jenkins again.

Also, it's based on devel and wasn't ready in time for the 2.10 freeze, so I guess it's a candidate for 2.12 (unless it can actually be merged into current testing, in which case please set its base branch to something else than devel?).

Well, we haven't had issues with merging test/ branches after freezes before, so I still think 2.10 is a good target. I let you decide (so I merged testing instead of devel), taking into account that you probably have higher prio stuff to focus on.

#8 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to anonym
  • QA Check changed from Ready for QA to Info Needed

I've skimmed over the log -p and the diff, and it looks good!

One question though: why is the port (/dev/ttyS0) now hard-coded in the script, rather than passed on the command line as it was the case previously?

#9 Updated by anonym over 2 years ago

  • Assignee changed from anonym to intrigeri
  • QA Check changed from Info Needed to Ready for QA

intrigeri wrote:

One question though: why is the port (/dev/ttyS0) now hard-coded in the script, rather than passed on the command line as it was the case previously?

See:

9fb70d9c6e Revert back to serial link for the remote shell transport.

I had hardcoded the device used for the Virtio communication, and this was the more convenient way to revert to the serial link. IMHO, since this beast is so extremely Tails-specific, I see no real value in using parameters.

#10 Updated by anonym over 2 years ago

#11 Updated by anonym over 2 years ago

For the record, all Jenkins failures for this branch for the past week are unrelated.

#12 Updated by anonym over 2 years ago

  • Target version changed from Tails_2.12 to Tails_2.11

Its base branch is now stable.

#13 Updated by intrigeri over 2 years ago

  • Assignee changed from intrigeri to anonym
  • % Done changed from 50 to 70
  • QA Check changed from Ready for QA to Info Needed

In elapsed = (Time.now - TIME_AT_START.to_f - 3600).strftime("%H:%M:%S.%9N"), I don't understand the - 3600 part. Can you please explain?

Otherwise looks good, and Jenkins is pretty happy with it, so feel free to merge yourself with a comment added for the above question :)

#14 Updated by anonym over 2 years ago

  • Assignee changed from anonym to intrigeri
  • % Done changed from 70 to 80
  • QA Check changed from Info Needed to Ready for QA

intrigeri wrote:

In elapsed = (Time.now - TIME_AT_START.to_f - 3600).strftime("%H:%M:%S.%9N"), I don't understand the - 3600 part. Can you please explain?

Err. Well, I remember that I initially was perplexed why it got offset by +1 hour, but I remember figuring out that it's the local timezone that is applied, so all we have to do is to force UTC. Fixed now!

Otherwise looks good, and Jenkins is pretty happy with it, so feel free to merge yourself with a comment added for the above question :)

Well, let's see if the current change makes enough sense to you. Please review'n'merge!

#15 Updated by intrigeri over 2 years ago

  • Status changed from In Progress to Fix committed
  • % Done changed from 80 to 100

#16 Updated by intrigeri over 2 years ago

  • Assignee deleted (intrigeri)
  • QA Check changed from Ready for QA to Pass

#17 Updated by anonym over 2 years ago

  • Status changed from Fix committed to Resolved

Also available in: Atom PDF