TODO 5.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128
  1. --------------------------------------------------------
  2. The Corosync Cluster Engine Topic Branches and Backlog
  3. --------------------------------------------------------
  4. ----------------------------
  5. Last Updated: January 2012
  6. ----------------------------
  7. --------------------------------------
  8. Current priority list for Needle 2.0
  9. --------------------------------------
  10. 1. quorum improvements
  11. 2. allow a cluster name to autogenerate a mcastaddr
  12. 3. ring status change via corosync-notifyd
  13. --------------------------------------
  14. Current priority list for Needle 2.1
  15. --------------------------------------
  16. 1. implement topic-onecrypt
  17. 2. implement add/remove nodes from udpu
  18. 3. logsys glue layer removal
  19. 4. implement topic-zerocopy
  20. 5. implement topic-rdmaud
  21. 6. harden and finish ykd algorithm
  22. 7. implement topic-xmlschema
  23. We use topic branches in our git repository to develop new disruptive features
  24. that define our future roadmap. This file describes the topic branches
  25. the developers have interest in investigating further.
  26. targets can be: whitetank, needle2.0, needle3.0, or future (3.0+).
  27. Finished can be: percentage or date merged to master. Once in a shipped
  28. version, please remove from the topic list.
  29. ------------------------------------------------------------------------------
  30. topic-quorum
  31. ------------------------------------------------------------------------------
  32. Main Developer: Fabio "the coding monkey" Di Nitto
  33. Started: yes
  34. Finished: 75%
  35. target: needle2.0
  36. This topic is about bringing votequorum/quorum up to speed and feature complete.
  37. Current status:
  38. - features are implemented, most of debugging done
  39. - need to do:
  40. * man pages
  41. * documentation
  42. * votequorum lib/core cleanup
  43. * configuration bits in corosync.conf for quorum related business
  44. * improve corosync-quorumtool to show more details in some cases
  45. (config flags/votequorum info in monitoring at least)
  46. ------------------------------------------------------------------------------
  47. topic-xmlschema
  48. ------------------------------------------------------------------------------
  49. Main Developer: Honza Friesse
  50. Started: not started
  51. Finished: 0%
  52. target: needle2.1
  53. XML configuration for corosync exists, but imput file is not checked against
  54. XML schema. This topic is about implementing preferably RelaxNG schema of
  55. corosync configuration.
  56. ------------------------------------------------------------------------------
  57. topic-onecrypt
  58. ------------------------------------------------------------------------------
  59. Main Developer: Honza Friesse
  60. Started: not started
  61. Finished: 0%
  62. target: needle2.1
  63. Description:
  64. Currently encryption code is located in totemudp.c, totemudpu.c, and iba has
  65. no encryption support. This topic merges the encryption code into a new
  66. file such as totemcrp.c and provides a mechanism for totemnet.c to register
  67. encrypt and decrypt functions with totem[udp|iba|udpu] and use them as
  68. requested by the configuration.
  69. ------------------------------------------------------------------------------
  70. topic-netmalloc
  71. ------------------------------------------------------------------------------
  72. Main Developer: Honza Friesse
  73. Started: not started
  74. Finished: 0%
  75. target: needle2.1
  76. Description:
  77. The totemiba.c driver must allocate memory and assign it to a protection domain
  78. in order for an infiniband driver to transmit memory. In the current
  79. implementation, totemsrp.c also allocates these same frames. This results in
  80. an extra memcpy when transmitting with libibverbs technology. Memory copies
  81. are to be avoided. The simple solution is to have each network driver provide
  82. a memory allocation function. When totemsrp wants a free frame, it requests
  83. it from the network driver.
  84. ------------------------------------------------------------------------------
  85. topic-rdmaud
  86. ------------------------------------------------------------------------------
  87. Main Developer: Honza Friesse Steven Dake
  88. Started: not started
  89. Finished: 0%
  90. target: needle2.1
  91. Description:
  92. Currently our RDMA code uses librdmacm to setup connections. We are not
  93. certain this extra library is needed, and may be able to use only ibverbs. If
  94. this is possible, the totem code may be more reliable, especially around
  95. failure conditions.
  96. ------------------------------------------------------------------------------
  97. topic-zerocopy
  98. ------------------------------------------------------------------------------
  99. Main Developer: Honza Friesse
  100. Started: not started
  101. Finished: 0%
  102. target: needle2.1
  103. Description:
  104. Totem has many copies involved in messaging which we would like to investigate
  105. removing. Our goal is to deliver wire speed performance for rdma networks,
  106. and if this can be achieved by our other topic investigations, we may not
  107. further investigate this topic. The basic idea of the topic is to handle
  108. message assembly/fragmentation in libcpg, and have totem be responsible for
  109. sending these pages that are shared via posix shared memory.
  110. ------------------------------------------------------------------------------
  111. other topics not yet defined:
  112. * disallow binding to localhost interfae in redundant ring configuation.
  113. * doxygenize include and lib directories.
  114. * sort out binding to localhost in general
  115. * totem multiring
  116. * load balancing over different speed links in RRP