From e6918187568dbd01842d8d1d2c808ce16a894239 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sun, 21 Apr 2024 13:54:28 +0200 Subject: Adding upstream version 18.2.2. Signed-off-by: Daniel Baumann --- src/doc/mon-wishlist.txt | 51 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 src/doc/mon-wishlist.txt (limited to 'src/doc/mon-wishlist.txt') diff --git a/src/doc/mon-wishlist.txt b/src/doc/mon-wishlist.txt new file mode 100644 index 000000000..a5fb9422c --- /dev/null +++ b/src/doc/mon-wishlist.txt @@ -0,0 +1,51 @@ +Monitor Wish List (issue #10509) +================================ + +Low-hanging fruit +----------------- + +* audit helpers that put() messages but do not get() them. + where possible, get rid of those put(). No one expects helpers to + put() messages and that may lead to double frees. (issue #9378) + +Time consuming / complex +------------------------ + +* Split the OSDMonitor.cc file into auxiliary files. This will mean: + + 1. Logically split subsystems (osd crush, osd pool, ...) + 2. Split the big badass functions, especially prepare/process_command() + +* Have Tracked Ops on the monitor, similarly to the OSDs. (issue #10507) + + 1. Instead of passing messages back and forth, we will pass OpRequests + 2. We may be able to get() the message when we create the OpRequest and + put() it upon OpRequest destruction. This will help controlling the + lifespan of messages and reduce leaks. + 3. There will be a fair amount of work changing stuff from Messages to + OpRequests, and we will need to make sure that we reach a format that + is easily supported throughout the monitor + + Possible format, off the top of my head: + + MonOpRequest: + + int op = m->get_type(); + Message *m = m.get(); + + template + T* get_message() { return (T*)m.get(); } + +* Move to Ref'erenced messages instead of pointers all around. This would + also help with the Tracked Ops thing, as we'd be able to simply ignore all + the get() and put() stuff behind it. (issue #3500) + +Delicate / complex +------------------ + +* Finer-grained Paxos::is_readable() and/or PaxosService::is_readable() + (issue #10508) + + Rationale: a given service S should be able to read its committed state + even though a Paxos proposal is happening, as long as the on-going + proposal is not a value of service S. -- cgit v1.2.3