CA-134593: The recent introduction of the configure script missed INVENTORY

Signed-off-by: Jon Ludlam <jonathan.ludlam@citrix.com>
Merge pull request #1720 from jonludlam/CA-134593

CA-134593: The recent introduction of the configure script missed INVENT...
The Makefile shouldn't call 'configure'

The build 'standard' is that the caller should run
  ./configure
  make

Signed-off-by: David Scott <dave.scott@citrix.com>
configure: add '--disable-tests' option

Unfortunately the unit tests don't work when run as unpriviledged
users inside unprepared chroots. This allows them to be skipped.

By default "./configure && make" will run the unit tests as before.

Signed-off-by: David Scott <dave.scott@citrix.com>
xapi.spec: run "configure"

Signed-off-by: David Scott <dave.scott@citrix.com>
xenserver build: run configure from mk/Makefile

Signed-off-by: David Scott <dave.scott@citrix.com>
event.from: prevent interference between parallel calls

Since the new event.from API implementation was based on top
of the existing event.next implementation it was possible
for one thread to interfere with another because each event.from
*shared* the 'subscription' record. In particular CloudStack
suffered from the following interleaving:

thread 1: event.from ["vm/"]
thread 2: event.from ["task/"]
 <- event on vm
thread 1: return successfully
thread 2: fails with SESSION_INVALID because the subscription
  is marked as invalid in the on_session_deleted cleanup function

In this patch we cleanly separate the event.next implementation
(in the submodule Next) from the event.from implementation
(in the submodule From). It's now clear that all calls to
event.from use *separate* state, sharing only the session_id
which is used to allow session.logout to be used to unblock
blocked threads.

This patch strengthens the event.from postcondition: the only time
when an empty event set is returned is when the timeout has fired.
Previously empty sets could be triggered by the race:

1.     object is modified
2. event.from sees the modification
3.     object is destroyed
4. event.from cannot find the snapshot, omits the modify event

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
quicktest: add a test case for parallel calls to event.from

Sophisticated clients like CloudStack will issue parallel calls to
event.from, looking for different conditions. These calls should
not interfere.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Add nice Xapi_event .mli

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge pull request #1722 from djs55/fix-events.from-trunk

Fix races in events.from and add a test case (master edition)
Fix event.next after EVENTS_LOST

When recording the id of the latest dropped event, we need to sort the list of
ids as integers. Unfortunately in the forward port of the events.from patch from
clearwater-lcm-sp1 I accidentally sorted the list of ids as strings.

- : bool = false

- : bool = true

This corrupts the stored id, resulting in multiple EVENTS_LOST where only one
is expected.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Merge pull request #1724 from djs55/fix-event.next

Fix event.next after EVENTS_LOST
Merge pull request #1721 from djs55/experiment

Increase mock-friendliness
Don't "synchronise" domain 0's state with xenopsd

This results in domain 0's power_state being set to Halted, and
then the metadata being destroyed.

Signed-off-by: David Scott <dave.scott@eu.citrix.com>
Support multiple xenopsds, configurable per-VM

To override the default xenopsd set:
  VM.other_config:xenops = org.xen.xcp.xenops.NAME

Observe the following changes:
  1. xapi needs all configured xenopsd to be online before it can
     complete the initial VM sync. The xenopsd list is hardcoded.
  2. the control domain's power_state is not being synchronised
     with any xenopsd because (a) we always assume it should be
     Running, anyone who sets it to Halted triggers horrible bugs;
     and (b) which xenopsd should "own" it anyway?

Signed-off-by: David Scott <dave.scott@citrix.com>
xenopsd: read list and the default setting from the config file

xapi startup doesn't fully complete unless it can contact all
the xenopsd instances it wants to manage. It's easier to setup
a working system if the list can be tweaked via a config file
rather than a recompilation.

Although it's possible to override a xenopsd per-VM, it's also
convenient to set a host-wide default via the config file.

Signed-off-by: David Scott <dave.scott@citrix.com>
Remove ocaml/xenops: this is all stale code

Signed-off-by: David Scott <dave.scott@citrix.com>
Remove ocaml/rrdd: this is all stale code

Signed-off-by: David Scott <dave.scott@citrix.com>
Remove Vmopshelpers

Note we still have small dependencies on Xenctrl (boot time memory)
and Xenstore (VSS snapshots)

Signed-off-by: David Scott <dave.scott@citrix.com>
Fix the RPM build

Signed-off-by: David Scott <dave.scott@citrix.com>