← Back to branch summary

~jocave/checkbox/hybrid-amd-gpu-mods

« back to all changes in this revision

Viewing changes to cep/CEP-4.txt

  • Committer: Sylvain Pineau
  • Date: 2014-07-29 16:05:54 UTC
  • mto: This revision was merged to the branch mainline in revision 3149.
  • Revision ID: sylvain.pineau@canonical.com-20140729160554-qev8887xbunn9tmi
checkbox-ng:launchers:checkbox-cli: The checkbox-cli launcher

Running the default whitelist (with the suite selection screen skipped)

Show diffs side-by-side

added added

removed removed

Lines of Context:
cep/CEP-4.txt
1
 
======================
2
 
PlainBox Target Device
3
 
======================
4
 
 
5
 
This proposal describes a method for executing jobs remotely, on one device
6
 
(target), while running python3 and all of plainbox, on another device (host)
7
 
 
8
 
Rationale
9
 
=========
10
 
 
11
 
During the development of first external PlainBox provider for Ubuntu Touch, we
12
 
found that shipping python3, plainbox and a lot of data onto the phone and
13
 
table target is challenging. Not only is the root filesystem read only,
14
 
traditional package management is not available outside of non-standard
15
 
builds. For the purpose of testing systems as similar to production systems as
16
 
possible, making the root filesystem writable was rejected as an option.
17
 
Another possibility, that was initially pursued, was to wrap everything related
18
 
to plainbox and a set of providers into a big click package. While that
19
 
approach worked it was too not without challenges. In the end the process was
20
 
deemed to heavyweight and that idea was abandoned. This lead to the idea of
21
 
running plainbox locally, one a typical Ubuntu environment and using adb or ssh
22
 
to connect to the remote test target.
23
 
 
24
 
An experimental provider, using plainbox 0.4, used adb push and adb shell, to
25
 
copy the data and execute commands remotely. This approach was successful. This
26
 
proposal aims to implement that functionality across the framework, taking it
27
 
into account where appropriate.
28
 
 
29
 
Changes
30
 
=======
31
 
 
32
 
Unless otherwise noted, everything remains local. This specifically includes
33
 
session storage, which holds the bulk of the filesystem visible artifacts of a
34
 
running session. This keeps the existing workflow, result retrieval and tooling
35
 
identical in the remote and local use-cases.
36
 
 
37
 
PLAINBOX_SESSION_SHARE
38
 
----------------------
39
 
 
40
 
The primary difference is that PLAINBOX_SESSION_SHARE would no longer be
41
 
something that you can access locally. This is a temporary, per-session
42
 
directory where jobs can exchange data of any kind. This change would allow all
43
 
jobs to run the same, so no jobs would need to be modified for this setup to
44
 
work and all the existing local jobs would run remotely, producing the same
45
 
results.
46
 
 
47
 
(This is also known as CHECKBOX_DATA but this name is deprecated)
48
 
 
49
 
Execution controllers
50
 
---------------------
51
 
 
52
 
Execution controllers that prepare the environment for each job would
53
 
necessarily change. Existing set of controllers can run jobs as the regular
54
 
user, as a root user via sudo or as a root user via
55
 
plainbox-trusted-launcher-1.
56
 
 
57
 
In addition to user handing, those controllers handle the task of configuring
58
 
the filesystem for a specific job. The new remote controller would need to
59
 
ensure that provider data associated with the job that is to be executed is
60
 
copied (using rsync, adb push or other similar command).
61
 
 
62
 
Handling of root jobs would vary, depending on the capabilities of the remote
63
 
target. For the first version of this proposal we don't have sufficient data or
64
 
experience to draw conclusions as to how that should work exactly. The existing
65
 
mechanisms that allow execution controllers to bid on the execution of a
66
 
particular job is sufficient for specialized solutions to be accommodated,
67
 
though.
68
 
 
69
 
The act of running a job would need minor changes, specifically to transition
70
 
all of the required environment across to the target device. Existing sudo and
71
 
plainbox-trusted-launcher-1 execution controllers already offer that
72
 
functionality. Actual new execution controllers (here, presumably for ssh and
73
 
adb) would just prefix the command with the appropriate connection string and
74
 
rely on system-level configuration for making a successful connection. This
75
 
approach is flexible and could allow us to connect to a variety of targets,
76
 
including phones and tables (using adb), remote servers in the cloud (using
77
 
ssh) or development boards (using serial connections).
78
 
 
79
 
Session State Meta Data
80
 
-----------------------
81
 
 
82
 
Session state meta data should be expanded to accurately store connection
83
 
information as well as location of the temporary session storage directory.
84
 
 
85
 
This will necessitate another version increase in the on-disk persistent
86
 
storage used by plainbox but the necessary infrastructure, both for code and
87
 
testing, was developed a while ago, while we introduced the app_data field.
88
 
 
89
 
Command Line Interface
90
 
----------------------
91
 
 
92
 
PlainBox would grow a number of new command line arguments and options. The
93
 
precise set is not clear yet, and largely depends on how execution targets are
94
 
implemented. At the very least we'd like to provider a --target string, that
95
 
uses a pseudo-URL syntax for defining the target connection string and the
96
 
scheme to pick the target controller.
97
 
 
98
 
A simple session might look like:
99
 
 
100
 
    $ plainbox --target adb:some-serial-number run -i stub/true
101
 
 
102
 
Unresolved Issues
103
 
-----------------
104
 
 
105
 
The following issues are not resolved as of this time. We believe that by
106
 
implementing this proposal we will gain critical understanding and insight that
107
 
may allow us to explore those problems and come up with further enhancement.
108
 
 
109
 
1. Handling jobs that terminate host connection.
110
 
 
111
 
   Certain jobs may terminate the host connection by issuing reboots, suspends,
112
 
   or performing purposeful network reconfiguration. Such jobs will likely
113
 
   cause the execution controller to time out and abort the connection.
114
 
 
115
 
2. Handling sandboxing and general remote user constraints.
116
 
 
117
 
   Remote execution targets may differ widely, compared to our traditional
118
 
   environments. It is uncertain if our current abstractions are sufficient for
119
 
   handling user identity changes and general privilege elevation tasks.
120
 
 
121
 
3. Local and remote interaction.
122
 
 
123
 
   Implementation of this proposal will open up interesting possibilities,
124
 
   including interactions of jobs executed locally and remotely within a single
125
 
   session.
126
 
 
127
 
   This task is mentioned but not explored, as we are unsure about the exact
128
 
   requirements as this time. Such interactions may include:
129
 
 
130
 
   * having jobs that execute locally to verify presence, access and
131
 
     configuration of a remote target
132
 
   * having jobs that provision and tear down the remote target
133
 
   * having multiple remote targets cooperate during a single execution session