CA-420987: xapi_message: Add message-destroy-all API

[cplaursen]

We've seen issues where a client will try to dismiss all their alerts and fail due to the message-destroy call hitting the maximum XAPI request size at ~5000 messages.

A new message-destroy-all API avoids this issue while saving the bandwidth required to send a ref for each message.

[psafont]

Could we have an alternative approach where messages are deleted depending on a filter? In particular by age and by priority are interesting here.

[lindig]

If you would like to over-engineer this:

• https://github.com/lindig/expr/ my little library for an expression language over variables, floats, and bools
• you can bind various variables, like age, or error level to variables that then become available in expressions

exception Failure of string

type expression
type value = Bool of bool | Float of float
type env

val empty : unit -> env
val add : env -> string -> float -> unit
val add' : env -> string list -> float -> unit
val env : (string * float) list -> env
val compile : string -> expression
val string : env -> string -> value
val expr : env -> expression -> value
val simple : string -> value

You can provide an environment that binds names to values and an expression which then can be evaluated:

$ make utop
utop # Expr.Eval.simple "3+4*5 == 23";;
- : Expr.Eval.value = Expr.Eval.Bool true

utop # let env = Expr.Eval.env ["pi", Float.pi] in
  Expr.Eval.string env "pi * pi";;
- : Expr.Eval.value = Expr.Eval.Float 9.86960440108935799

If you want to do this, would suggest to just copy the lib/ directory that contains the library and not create an opam dependency.

[cplaursen]

@psafont I've added parameters to select messages to delete by priority, before a timestamp, and after a timestamp. Is this what you were hoping for?
The code is quite messy so I'll clean it up then open the pull request for review.

[cplaursen]

@lindig I'll keep it simple for now, I don't see a need for advanced filtering though it would be a fun thing to do. If the frontend people need it I can always add it with an extra filter= parameter.

[psafont]

The current PR only modifies the CLI interface (xe is its only user), and doesn't modify the API for Xencenter, is this intended?
To modify the API, the functions are in ocaml/idl and, maybe https://github.com/xapi-project/xen-api/blob/master/ocaml/xapi/xapi_message.ml as well

[cplaursen]

Thanks for that, I've added the new message to idl and moved the implementation over to xapi_message

[cplaursen]

Just tested it and the command works as expected.

[changlei-li]

I think with the params, the API is not convenient to use.
I have tested the python SDK:

session.xenapi.message.destroy_all()
session.xenapi.message.destroy_all('20251222T00:00:00Z', '20251222T00:00:00Z', 1)

are OK.

session.xenapi.message.destroy_all(1)
session.xenapi.message.destroy_all(priority=1)

failed.
named param is not supported, then the user has to provide all the three params even if he may just want to filter the priority.

Would you consider a new API destroy_all_where, referring to message.get_all_records_where, while the destroy_all will not filter any conditions. Seems where expr is not suitable either. I have no better idea about this.

[lindig]

I believe the documentation should say explicitly if conditions are logically and or or: have all conditions to be met or just at least one? What happens of no conditions are provided?

[psafont]

Only a minor comment about docs and some unexpected changes

[psafont]

Is there a place where the values of different priorities are explained? It would be useful here

[lindig]

Would a different API be more convenient?

• an single timestamp
• a direction: before/after
  with the semantics that all messages before/after the timestamp are removed. I would imagine that this is the common use case.

[lindig]

Would a different API be more convenient?

• an single timestamp
• a direction: before/after
  with the semantics that all messages before/after the timestamp are removed. I would imagine that this is the common use case.

[cplaursen]

The destroy_all call now accepts an assoc list of optional parameters: priority, before, and after. These are optional parameters of the CLI call. Still need to test but all being well I think this should be fine to merge.

[lindig]

I believe the documentation should say explicitly if conditions are logically and or or: have all conditions to be met or just at least one? What happens of no conditions are provided?