)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"52cecaf4a4642337fae025ba2f1577fe9cbe8c37","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"85c2055f_d78b4066","updated":"2025-09-27 07:59:11.000000000","message":"I have been playing with this serie of patchs locally on a very small deployment (dev).\nIt works!\nThank you for this, it sounds a great achievement.\nI applied it on both nova and neutron, and I was able to spawn an instance successfully. YAY!\n\nI suspect that the RPC calls are even faster than when relying on rabbitmq, but I can\u0027t prove that (it\u0027s a feeling).\n\nI like the fact that there is no need for reply queues, as it rely on http reqs/resp mechanism, so there is no need to actually have a rpc server everywhere (like nova-api / neutron-api don\u0027t need it).\n\nI also like the consul registration, which act as an exchange, giving the address of the servers to be contacted to clients.\nHowever, I believe we are missing some documentation about how to effectively deploy and operate a consul service in that situation.\nThere is many ways to deploy consul, but I believe what is needed here is mostly a cluster of 3 nodes (or more /scaling) to ensure redundancy and stable operation.\nIMHO that should be defined somewhere to let the operator exactly know what is expected from consul. Another question: is the datacenter feature of consul useful?\n\nAnother thing is the new http_broadcaster service.\nFirst, there is no documentation at all on how to deploy it.\nIt\u0027s not a big deal, but again, that would be great to have a clean doc/explanation on how to deploy it.\nAlso, I believe the system supports having more than one broadcaster running (I tested only with one), but it should be explicitly said in a doc to avoid any additional question from operators.\nLast thing about this broadcaster: it makes oslo-messaging become a full standalone project providing a service to openstack. That\u0027s not a big deal in my opinion but it\u0027s worth to be noticed.\n\nAnd last but not least, the fact that we need a very big port range (from 10000 to 20000 by default) is a real pain IMHO.\nThis is complexifying a lot the deployment of openstack components.\nMaybe I used it wrong, but I have the feeling that the reverse_proxy_endpoint is a solution to this problem, but maybe we are lacking some documentation on how to deploy such proxy? Could the proxy be turned on by default and be deployed alongside the wsgi apps so that an operator would only have to open 1 port for each service?\n\nThank you again for this hard work!","commit_id":"eec16ea66d9aaa6c95a3f79e2a01a15e53988e66"},{"author":{"_account_id":36129,"name":"Xiang Wang","display_name":"Xiang(Roger) Wang","email":"rogerxiang.wang@gmail.com","username":"xiang-roger-wang"},"change_message_id":"56eceb14f955320f12470a8bf063cdf4266e0bd5","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":6,"id":"a28a862b_82a3e1f3","in_reply_to":"85c2055f_d78b4066","updated":"2026-01-08 16:57:28.000000000","message":"Sorry for the late reply. I finally managed to get some time recently to work on this again.\n\nThanks a lot for testing this out and for the very helpful feedback. It is really great to hear that it works for you and that you were able to spawn instances with nova and neutron.\n\nYou are totally right about the lack of documentation, and sorry about that. My initial plan was to first address review comments and get the patches close to final, since there were still ongoing discussions and possible changes such as option names and behavior.\n\nNow that the patches are almost finalized, I plan to start writing proper documentation and should have something ready in one or two weeks. I hope that will answer most of your questions and concerns, and we can continue the discussion from there.\n\nThanks again for taking the time to test this and share your thoughts.","commit_id":"eec16ea66d9aaa6c95a3f79e2a01a15e53988e66"},{"author":{"_account_id":36129,"name":"Xiang Wang","display_name":"Xiang(Roger) Wang","email":"rogerxiang.wang@gmail.com","username":"xiang-roger-wang"},"change_message_id":"322433dfa0f2d45900649023524320d652294eb7","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"d9979743_999fc3e6","in_reply_to":"a28a862b_82a3e1f3","updated":"2026-01-19 15:11:15.000000000","message":"As discussed, i\u0027ve added the documentation in my latest patch [1].\nIt would be great if you can take a look and let me know if any questions or concerns. And we can continue to follow up there.  \n\n[1] https://review.opendev.org/c/openstack/oslo.messaging/+/973843","commit_id":"eec16ea66d9aaa6c95a3f79e2a01a15e53988e66"}],"oslo_messaging/_drivers/impl_http.py":[{"author":{"_account_id":11583,"name":"Arnaud Morin","email":"arnaud.morin@gmail.com","username":"arnaudmorin"},"change_message_id":"fa078f52050d65eb0f038662f5533d9d55f40c09","unresolved":true,"context_lines":[{"line_number":304,"context_line":"            return None"},{"line_number":305,"context_line":""},{"line_number":306,"context_line":"    def _create_server(self):"},{"line_number":307,"context_line":"        start \u003d self.port_range_min"},{"line_number":308,"context_line":"        end \u003d self.port_range_max"},{"line_number":309,"context_line":"        port \u003d secrets.choice(range(start, end))"},{"line_number":310,"context_line":"        initial_port \u003d port"}],"source_content_type":"text/x-python","patch_set":6,"id":"80b868d5_ed79bb69","line":307,"updated":"2025-09-24 22:53:13.000000000","message":"I am worried about the port range here.\n\nI run nova-conductor within kubernetes pods.\nSince now, nova-conductor was serviceless, but as we start a wsgi server now, I created a service.\nI had to choose a port.\nI selected port 10000.\nBut nova-conductor is starting multiple workers, selecting ports randomly from that range...","commit_id":"eec16ea66d9aaa6c95a3f79e2a01a15e53988e66"}]}