← 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: Zygmunt Krynicki
  • Date: 2014-12-19 12:11:52 UTC
  • mto: This revision was merged to the branch mainline in revision 3516.
  • Revision ID: zygmunt.krynicki@canonical.com-20141219121152-y9vtxajhrd6e1c3l
cep: merge CEPs in to trunk

This patch merges CEPs (aka Checkbox Enhancement Proposals) into trunk.
Those lived on separately for a while as lp:checkbox/cep but in
retrospective nobody knows about them and this should give them some
more exposure. In addition, the move allows new features to land a CEP
document along, making review of complex new features easier to make as
their specification can be seen alongside the patches that implement it.

Due to bazaar limitations in merging separate repositories together I've
discarded history entries (not that there were many) and just added
those files in directly.

Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com>

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