Skip to content

Commit bbffffe

Browse files
committed
Merge branch 'master' into private/bengangy/master-to-easy-pool-join
2 parents b3e1ec1 + 43d01ca commit bbffffe

File tree

124 files changed

+3343
-2768
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

124 files changed

+3343
-2768
lines changed

.github/workflows/release.yml

Lines changed: 2 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -20,13 +20,11 @@ jobs:
2020
python-version: "3.x"
2121

2222
- name: Install build dependencies
23-
run: |
24-
pip install build
25-
sudo apt-get install ocaml dune libfindlib-ocaml-dev libdune-ocaml-dev libcmdliner-ocaml-dev
23+
run: pip install build
2624

2725
- name: Generate python package for XenAPI
2826
run: |
29-
./configure --xapi_version=${{ github.ref_name }}
27+
echo "export XAPI_VERSION=${{ github.ref_name }}" > config.mk
3028
make python
3129
3230
- name: Store python distribution artifacts

doc/content/design/coverage/index.md

Lines changed: 19 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@ revision: 2
88

99
We would like to add optional coverage profiling to existing [OCaml]
1010
projects in the context of [XenServer] and [XenAPI]. This article
11-
presents how we do it.
11+
presents how we do it.
1212

1313
Binaries instrumented for coverage profiling in the XenServer project
1414
need to run in an environment where several services act together as
@@ -21,7 +21,7 @@ isolation.
2121
To build binaries with coverage profiling, do:
2222

2323
./configure --enable-coverage
24-
make
24+
make
2525

2626
Binaries will log coverage data to `/tmp/bisect*.out` from which a
2727
coverage report can be generated in `coverage/`:
@@ -38,7 +38,7 @@ and logs during execution data to in-memory data structures. Before an
3838
instrumented binary terminates, it writes the logged data to a file.
3939
This data can then be analysed with the `bisect-ppx-report` tool, to
4040
produce a summary of annotated code that highlights what part of a
41-
codebase was executed.
41+
codebase was executed.
4242

4343
[BisectPPX] has several desirable properties:
4444

@@ -65,13 +65,13 @@ abstracted by OCamlfind (OCaml's library manager) and OCamlbuild
6565

6666
# build it with instrumentation from bisect_ppx
6767
ocamlbuild -use-ocamlfind -pkg bisect_ppx -pkg unix example.native
68-
68+
6969
# execute it - generates files ./bisect*.out
7070
./example.native
71-
71+
7272
# generate report
7373
bisect-ppx-report -I _build -html coverage bisect000*
74-
74+
7575
# view coverage/index.html
7676

7777
Summary:
@@ -86,7 +86,7 @@ will be instrumented during compilation. Behind the scenes `ocamlfind`
8686
makes sure that the compiler uses a preprocessing step that instruments
8787
the code.
8888

89-
## Signal Handling
89+
## Signal Handling
9090

9191
During execution the code instrumentation leads to the collection of
9292
data. This code registers a function with `at_exit` that writes the data
@@ -98,7 +98,7 @@ terminated by receiving the `TERM` signal, a signal handler must be
9898
installed:
9999

100100
let stop signal =
101-
printf "caught signal %d\n" signal;
101+
printf "caught signal %a\n" Debug.Pp.signal signal;
102102
exit 0
103103

104104
Sys.set_signal Sys.sigterm (Sys.Signal_handle stop)
@@ -149,8 +149,8 @@ environment variable. This can happen on the command line:
149149

150150
BISECT_FILE=/tmp/example ./example.native
151151

152-
In the context of XenServer we could do this in startup scripts.
153-
However, we added a bit of code
152+
In the context of XenServer we could do this in startup scripts.
153+
However, we added a bit of code
154154

155155
val Coverage.init: string -> unit
156156

@@ -176,12 +176,12 @@ Goals for instrumentation are:
176176

177177
* what files are instrumented should be obvious and easy to manage
178178
* instrumentation must be optional, yet easy to activate
179-
* avoid methods that require to keep several files in sync like multiple
179+
* avoid methods that require to keep several files in sync like multiple
180180
`_oasis` files
181181
* avoid separate Git branches for instrumented and non-instrumented
182182
code
183183

184-
In the ideal case, we could introduce a configuration switch
184+
In the ideal case, we could introduce a configuration switch
185185
`./configure --enable-coverage` that would prepare compilation for
186186
coverage instrumentation. While [Oasis] supports the creation of such
187187
switches, they cannot be used to control build dependencies like
@@ -196,7 +196,7 @@ rules in file `_tags.coverage` that cause files to be instrumented:
196196

197197
leads to the execution of this code during preparation:
198198

199-
coverage: _tags _tags.coverage
199+
coverage: _tags _tags.coverage
200200
test ! -f _tags.orig && mv _tags _tags.orig || true
201201
cat _tags.coverage _tags.orig > _tags
202202

@@ -207,7 +207,7 @@ could be tweaked to instrument only some files:
207207
<**/*.native>: pkg_bisect_ppx
208208

209209
When `make coverage` is not called, these rules are not active and
210-
hence, code is not instrumented for coverage. We believe that this
210+
hence, code is not instrumented for coverage. We believe that this
211211
solution to control instrumentation meets the goals from above. In
212212
particular, what files are instrumented and when is controlled by very
213213
few lines of declarative code that lives in the main repository of a
@@ -226,14 +226,14 @@ coverage analysis are:
226226
The `_oasis` file bundles the files under `profiling/` into an internal
227227
library which executables then depend on:
228228

229-
# Support files for profiling
229+
# Support files for profiling
230230
Library profiling
231231
CompiledObject: best
232232
Path: profiling
233233
Install: false
234234
Findlibname: profiling
235235
Modules: Coverage
236-
BuildDepends:
236+
BuildDepends:
237237

238238
Executable set_domain_uuid
239239
CompiledObject: best
@@ -243,16 +243,16 @@ library which executables then depend on:
243243
MainIs: set_domain_uuid.ml
244244
Install: false
245245
BuildDepends:
246-
xenctrl,
247-
uuidm,
246+
xenctrl,
247+
uuidm,
248248
cmdliner,
249249
profiling # <-- here
250250

251251
The `Makefile` target `coverage` primes the project for a profiling build:
252252

253253
# make coverage - prepares for building with coverage analysis
254254

255-
coverage: _tags _tags.coverage
255+
coverage: _tags _tags.coverage
256256
test ! -f _tags.orig && mv _tags _tags.orig || true
257257
cat _tags.coverage _tags.orig > _tags
258258

doc/content/xen-api/basics.md

Lines changed: 77 additions & 71 deletions
Original file line numberDiff line numberDiff line change
@@ -3,14 +3,16 @@ title = "XenAPI Basics"
33
weight = 10
44
+++
55

6-
This document contains a description of the Xen Management API an interface for
6+
This document contains a description of the Xen Management API - an interface for
77
remotely configuring and controlling virtualised guests running on a
88
Xen-enabled host.
99

10-
The XenAPI is presented here as a set of Remote Procedure Calls, with a wire
11-
format based upon [XML-RPC](http://xmlrpc.scripting.com).
12-
No specific language bindings are prescribed,
13-
although examples will be given in the python programming language.
10+
The API is presented here as a set of Remote Procedure Calls (RPCs).
11+
There are two supported wire formats, one based upon
12+
[XML-RPC](http://xmlrpc.scripting.com/spec.html)
13+
and one based upon [JSON-RPC](http://www.jsonrpc.org) (v1.0 and v2.0 are both
14+
recognized). No specific language bindings are prescribed, although examples
15+
are given in the Python programming language.
1416

1517
Although we adopt some terminology from object-oriented programming,
1618
future client language bindings may or may not be object oriented.
@@ -21,98 +23,102 @@ specific values. Objects are persistent and exist on the server-side.
2123
Clients may obtain opaque references to these server-side objects and then
2224
access their fields via get/set RPCs.
2325

24-
For each class we specify a list of fields along with their _types_ and _qualifiers_. A
25-
qualifier is one of:
26+
For each class we specify a list of fields along with their _types_ and
27+
_qualifiers_. A qualifier is one of:
2628

27-
- _RO/runtime_: the field is Read
28-
Only. Furthermore, its value is automatically computed at runtime.
29-
For example: current CPU load and disk IO throughput.
30-
- _RO/constructor_: the field must be manually set
31-
when a new object is created, but is then Read Only for
32-
the duration of the object's life.
33-
For example, the maximum memory addressable by a guest is set
34-
before the guest boots.
35-
- _RW_: the field is Read/Write. For example, the name of a VM.
29+
- _RO/runtime_: the field is Read Only. Furthermore, its value is
30+
automatically computed at runtime. For example, current CPU load and disk IO
31+
throughput.
3632

37-
Types
38-
-----
33+
- _RO/constructor_: the field must be manually set when a new object is
34+
created, but is then Read Only for the duration of the object's life.
35+
For example, the maximum memory addressable by a guest is set
36+
before the guest boots.
37+
38+
- _RW_: the field is Read/Write. For example, the name of a VM.
39+
40+
## Types
3941

4042
The following types are used to specify methods and fields in the API Reference:
4143

42-
- `string`: Text strings.
43-
- `int`: 64-bit integers.
44-
- `float`: IEEE double-precision floating-point numbers.
45-
- `bool`: Boolean.
46-
- `datetime`: Date and timestamp.
47-
- `c ref`: Reference to an object of class `c`.
48-
- `t set`: Arbitrary-length set of values of type `t`.
49-
- `(k → v) map`: Mapping from values of type `k` to values of type `v`.
50-
- `e enum`: Enumeration type with name `e`. Enums are defined in the API Reference together with classes that use them.
51-
52-
Note that there are a number of cases where `ref`s are _doubly
53-
linked_ – e.g. a VM has a field called `VIFs` of type
54-
`VIF ref set`; this field lists
55-
the network interfaces attached to a particular VM. Similarly, the VIF
56-
class has a field called `VM` of type `VM ref` which references the VM to which the interface is connected.
44+
- `string`: Text strings.
45+
- `int`: 64-bit integers.
46+
- `float`: IEEE double-precision floating-point numbers.
47+
- `bool`: Boolean.
48+
- `datetime`: Date and timestamp.
49+
- `c ref`: Reference to an object of class `c`.
50+
- `t set`: Arbitrary-length set of values of type `t`.
51+
- `(k -> v) map`: Mapping from values of type `k` to values of type `v`.
52+
- `e enum`: Enumeration type with name `e`. Enums are defined in the API
53+
reference together with classes that use them.
54+
55+
Note that there are a number of cases where `ref`s are _doubly linked_.
56+
For example, a `VM` has a field called `VIFs` of type `VIF ref set`;
57+
this field lists the network interfaces attached to a particular VM.
58+
Similarly, the `VIF` class has a field called `VM` of type `VM ref`
59+
which references the VM to which the interface is connected.
5760
These two fields are _bound together_, in the sense that
5861
creating a new VIF causes the `VIFs` field of the corresponding
5962
VM object to be updated automatically.
6063

61-
The API reference explicitly lists the fields that are
64+
The API reference lists explicitly the fields that are
6265
bound together in this way. It also contains a diagram that shows
6366
relationships between classes. In this diagram an edge signifies the
64-
existance of a pair of fields that are bound together, using standard
67+
existence of a pair of fields that are bound together, using standard
6568
crows-foot notation to signify the type of relationship (e.g.
6669
one-many, many-many).
6770

68-
RPCs associated with fields
69-
---------------------------
71+
## RPCs associated with fields
72+
73+
Each field, `f`, has an RPC accessor associated with it that returns `f`'s value:
74+
75+
- `get_f (r)`: takes a `ref`, `r` that refers to an object and returns the value
76+
of `f`.
77+
78+
Each field, `f`, with qualifier _RW_ and whose outermost type is `set` has the
79+
following additional RPCs associated with it:
7080

71-
Each field, `f`, has an RPC accessor associated with it
72-
that returns `f`'s value:
81+
- `add_f(r, v)`: adds a new element `v` to the set.
82+
Note that sets cannot contain duplicate values, hence this operation has
83+
no action in the case that `v` is already in the set.
7384

74-
- `get_f (r)`: Takes a `ref`, `r`, that refers to an object and returns the value of `f`.
85+
- `remove_f(r, v)`: removes element `v` from the set.
7586

76-
Each field, `f`, with attribute `RW` and whose outermost type is `set` has the following
77-
additional RPCs associated with it:
87+
Each field, `f`, with qualifier _RW_ and whose outermost type is `map` has the
88+
following additional RPCs associated with it:
7889

79-
- `add_f (r, v)`: Adds a new element `v` to the set. Since sets cannot contain duplicate values this operation has no action in the case
80-
that `v` was already in the set.
90+
- `add_to_f(r, k, v)`: adds new pair `k -> v` to the mapping stored in `f` in
91+
object `r`. Attempting to add a new pair for duplicate key, `k`, fails with a
92+
`MAP_DUPLICATE_KEY` error.
8193

82-
- `remove_f (r, v)`: Removes element `v` from the set.
94+
- `remove_from_f(r, k)`: removes the pair with key `k`
95+
from the mapping stored in `f` in object `r`.
8396

84-
Each field, `f`, with attribute RW and whose outermost type is `map` has the following
85-
additional RPCs associated with it:
97+
Each field whose outermost type is neither `set` nor `map`, but whose
98+
qualifier is _RW_ has an RPC accessor associated with it that sets its value:
8699

87-
- `add_to_f (r, k, v)`: Adds new pair `(k → v)` to the mapping stored in `f` in object `r`. Attempting to add a new pair for duplicate
88-
key, `k`, fails with an `MAP_DUPLICATE_KEY` error.
89-
- `remove_from_f (r, k)`: Removes the pair with key `k` from the mapping stored in `f` in object `r`.
100+
- `set_f(r, v)`: sets the field `f` on object `r` to value `v`.
90101

91-
Each field whose outermost type is neither `set` nor `map`,
92-
but whose attribute is RW has an RPC accessor associated with it
93-
that sets its value:
102+
## RPCs associated with classes
94103

95-
- `set_f (r, v)`: Sets field `f` on object `r` to value `v`.
104+
- Most classes have a _constructor_ RPC named `create` that
105+
takes as parameters all fields marked _RW_ and _RO/constructor_. The result
106+
of this RPC is that a new _persistent_ object is created on the server-side
107+
with the specified field values.
96108

97-
RPCs associated with classes
98-
----------------------------
109+
- Each class has a `get_by_uuid(uuid)` RPC that returns the object
110+
of that class that has the specified `uuid`.
99111

100-
- Most classes have a _constructor_ RPC named `create` that
101-
takes as parameters all fields marked RW and
102-
RO/constructor. The result of this RPC is that a new _persistent_ object is
103-
created on the server-side with the specified field values.
104-
- Each class has a `get_by_uuid (uuid)` RPC that returns the object
105-
of that class that has the specified UUID.
106-
- Each class that has a `name_label` field has a `get_by_name_label (name_label)` RPC that returns a set of objects of that
107-
class that have the specified `name_label`.
108-
- Most classes have a `destroy (r)` RPC that explicitly deletes the persistent object specified by `r` from the system. This is a
109-
non-cascading delete – if the object being removed is referenced by another
110-
object then the `destroy` call will fail.
112+
- Each class that has a `name_label` field has a
113+
`get_by_name_label(name_label)` RPC that returns a set of objects of that
114+
class that have the specified `name_label`.
111115

112-
Additional RPCs
113-
---------------
116+
- Most classes have a `destroy(r)` RPC that explicitly deletes
117+
the persistent object specified by `r` from the system. This is a
118+
non-cascading delete - if the object being removed is referenced by another
119+
object then the `destroy` call will fail.
114120

115-
As well as the RPCs enumerated above, most classes have additional RPCs
116-
associated with them. For example, the VM class has RPCs for cloning,
121+
Apart from the RPCs enumerated above, most classes have additional RPCs
122+
associated with them. For example, the `VM` class has RPCs for cloning,
117123
suspending, starting etc. Such additional RPCs are described explicitly
118124
in the API reference.

0 commit comments

Comments
 (0)