Skip to content

Conversation

@cplaursen
Copy link
Contributor

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.

@cplaursen cplaursen marked this pull request as draft December 17, 2025 13:46
@psafont
Copy link
Member

psafont commented Dec 17, 2025

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
Copy link
Contributor

lindig commented Dec 18, 2025

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
Copy link
Contributor Author

@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
Copy link
Contributor Author

@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.

Copy link
Member

@psafont psafont left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor Author

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

make_param_funs was building up a list by applying List.map and
List.filter several times. This commit combines and streamlines these.

Signed-off-by: Christian Pardillo Laursen <christian.pardillolaursen@citrix.com>
@cplaursen cplaursen force-pushed the destroy-all branch 2 times, most recently from aa8b729 to 627b221 Compare December 19, 2025 15:52
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. Users of the new
API call can choose to dismiss messages that arrived before or after
a certain date, or only those with a given priority.

Signed-off-by: Christian Pardillo Laursen <christian.pardillolaursen@citrix.com>
@cplaursen
Copy link
Contributor Author

Just tested it and the command works as expected.

@cplaursen cplaursen marked this pull request as ready for review December 19, 2025 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants