New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 703261 link

Starred by 2 users

Issue metadata

Status: Archived
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug
okr

Blocking:
issue 703256



Sign in to add a comment

Migrate autoserv to virtualenv

Project Member Reported by akes...@chromium.org, Mar 20 2017

Issue description

Plan of action:

 - add a global/shadow config variable to enable autoserv-in-virtualenv. This will allow us to preserve existing non-virtualenv behavior on all desktop (test_that etc) and moblab machines.
 - In the entry points given by example CLs below, wrap autoserv invocation in virtualenv. There are at least 2 distinct flows we need to touch: special tasks, and tests:

Special tasks:
https://chromium-review.googlesource.com/#/c/318753/
Tests:
https://chromium-review.googlesource.com/#/c/315230/14/scheduler/monitor_db.py


To consider later: how to get autoserv running in the virtualenv inside the SSP container. However, since SSP autoserv is already not able to send metrics (crbug.com/676696) and this is already broken, we don't need to block on fixing it for now.
 
Owner: akes...@chromium.org
Status: Started (was: Untriaged)
I'll take a crack at this...

Comment 2 by autumn@chromium.org, Mar 21 2017

Labels: -current-issue
Project Member

Comment 3 by bugdroid1@chromium.org, Mar 22 2017

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/d3e2c28c101f91934319a99b32e94bd0757a5c31

commit d3e2c28c101f91934319a99b32e94bd0757a5c31
Author: Aviv Keshet <akeshet@chromium.org>
Date: Wed Mar 22 11:23:19 2017

autotest: add a virtualenv_autoserv entry point that uses virtualenv

This CL creates a virtualenv entry point for autoserv, and some plumbing
to the command-line-generation functions, but does not enable it
anywhere.

BUG= chromium:703261 
TEST=server/virtualenv_autoserv -> starts autoserv in virtualenv as
expected, and doesn't blow up

Change-Id: Ibcb09cb5d57c49c77f8772c2fb0f0b0fca344535
Reviewed-on: https://chromium-review.googlesource.com/457225
Commit-Ready: Aviv Keshet <akeshet@chromium.org>
Tested-by: Aviv Keshet <akeshet@chromium.org>
Reviewed-by: Allen Li <ayatane@chromium.org>
Reviewed-by: Simran Basi <sbasi@chromium.org>

[add] https://crrev.com/d3e2c28c101f91934319a99b32e94bd0757a5c31/server/virtualenv_autoserv
[modify] https://crrev.com/d3e2c28c101f91934319a99b32e94bd0757a5c31/server/autoserv_utils.py
[add] https://crrev.com/d3e2c28c101f91934319a99b32e94bd0757a5c31/server/autoserv.py

Cc: akes...@chromium.org
Owner: ----
Status: Available (was: Started)
Not currently working on this, though it is still eventually desired.
What work remains?
Probably phase 1
1) add a config flag to global/shadow config that scheduler checks to determine whether to use virtualenv wrapper version of autoserv
2) actually respect that flag


Phase 2
1) Figure out the story for autoserv-virtualenv inside the ssp container (this would have made things like Issue 676696 much simpler)

Labels: OKR
Components: -Infra>Client>ChromeOS Infra>Client>ChromeOS>Test
Labels: -OKR okr
Owner: ayatane@chromium.org
Status: Assigned (was: Available)
How is this relevant if it all in the lucifer/swarming context?
Not very; we're planning to not touch autoserv at all for skylab.
Status: Archived (was: Assigned)
This will be done as part of Issue 810460

Sign in to add a comment