)]}'
{"doc/source/reference/developer/specs/enhanced-regional-executors.rst":[{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"2748f03c34587a9e4a0cd077bdf767cea8f11010","unresolved":false,"context_lines":[{"line_number":92,"context_line":"   * Address of executor if source zone is null or matches the zone of the"},{"line_number":93,"context_line":"     executor running the build."},{"line_number":94,"context_line":"   * Address of fingergw in the target zone if build is running on an executor"},{"line_number":95,"context_line":"     in a different zone"},{"line_number":96,"context_line":"* Fingergw connects to the stream address, supplies the build uuid and connects"},{"line_number":97,"context_line":"  the streams."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"4a61b054_e2feca77","line":95,"updated":"2021-03-29 22:42:38.000000000","message":"It\u0027s a little ambiguous, but I think \"source zone\" means \"the zone provided with the request\".  However, what about the case of an unzoned zuul-web making a request?  In that case, the scheduler should provide the zoned fingergw address.\n\nI think these rules should be:\n   * Address of executor if the zone provided with the request matches the zone of the executor running the build, or the executor is un-zoned.\n   * Address of fingergw in the target zone otherwise.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"65e95da2c8fa3998f319833260535de09b205e60","unresolved":false,"context_lines":[{"line_number":92,"context_line":"   * Address of executor if source zone is null or matches the zone of the"},{"line_number":93,"context_line":"     executor running the build."},{"line_number":94,"context_line":"   * Address of fingergw in the target zone if build is running on an executor"},{"line_number":95,"context_line":"     in a different zone"},{"line_number":96,"context_line":"* Fingergw connects to the stream address, supplies the build uuid and connects"},{"line_number":97,"context_line":"  the streams."},{"line_number":98,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"b060d18c_2d31c45e","line":95,"in_reply_to":"4a61b054_e2feca77","updated":"2021-03-31 07:18:59.000000000","message":"Done","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"2748f03c34587a9e4a0cd077bdf767cea8f11010","unresolved":false,"context_lines":[{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* The fingergw registers itself in gearman and offers its hostname, port and"},{"line_number":107,"context_line":"  optionally zone. The hostname further needs to be configurable like it is"},{"line_number":108,"context_line":"  for the executors."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"* Zuul-web and fingergw need a new optional config parameter containing their"},{"line_number":111,"context_line":"  zone."}],"source_content_type":"text/x-rst","patch_set":7,"id":"7dc520bc_4ebdee3b","line":108,"updated":"2021-03-29 22:42:38.000000000","message":"Perhaps we should go ahead and use the ZK component registry for this?","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"65e95da2c8fa3998f319833260535de09b205e60","unresolved":false,"context_lines":[{"line_number":105,"context_line":""},{"line_number":106,"context_line":"* The fingergw registers itself in gearman and offers its hostname, port and"},{"line_number":107,"context_line":"  optionally zone. The hostname further needs to be configurable like it is"},{"line_number":108,"context_line":"  for the executors."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"* Zuul-web and fingergw need a new optional config parameter containing their"},{"line_number":111,"context_line":"  zone."}],"source_content_type":"text/x-rst","patch_set":7,"id":"bd4bca7f_60010ea2","line":108,"in_reply_to":"7dc520bc_4ebdee3b","updated":"2021-03-31 07:18:59.000000000","message":"Yes, of course, that now makes much more sense since that now exists.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"2748f03c34587a9e4a0cd077bdf767cea8f11010","unresolved":false,"context_lines":[{"line_number":108,"context_line":"  for the executors."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"* Zuul-web and fingergw need a new optional config parameter containing their"},{"line_number":111,"context_line":"  zone."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Gearman"}],"source_content_type":"text/x-rst","patch_set":7,"id":"6d7f4f4b_05008665","line":111,"updated":"2021-03-29 22:42:38.000000000","message":"In the proposed change, we are adding zone information to zuul-web and zuul-fingergw, and I believe that is to support the idea that some or all of these services might be geographically distributed.  In other words (just focusing on zuul-web here): an operator may deploy a Zuul with 2 zuul-web processes, each of which is in an executor zone, and load balance between them.  These processes need to know their own zones so that they can make appropriate requests to fingergw services for log forwarding, however, they will be indistinguishable from each other for end users.  A user could connect to either one and will be able to access logs from anywhere.\n\nIt *almost* goes without saying since I believe universal accessibility is really the point of this spec, but it\u0027s still probably worth being clear that end users will never need to see or know anything about executor zoning, and that zuul-web and zuul-fingergw will still have a single canonical URL for end users to use and type into their address bars or terminals.  Maybe something like:\n\nWhile zuul-web and zuul-fingergw will be aware of what zone they are running in, end-users will not need this information; the user-facing instances of those services will continue to serve the entirely of the Zuul system regardless of which zone they reside in, all from a single public URL or address.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"65e95da2c8fa3998f319833260535de09b205e60","unresolved":false,"context_lines":[{"line_number":108,"context_line":"  for the executors."},{"line_number":109,"context_line":""},{"line_number":110,"context_line":"* Zuul-web and fingergw need a new optional config parameter containing their"},{"line_number":111,"context_line":"  zone."},{"line_number":112,"context_line":""},{"line_number":113,"context_line":""},{"line_number":114,"context_line":"Gearman"}],"source_content_type":"text/x-rst","patch_set":7,"id":"328b12d4_8b9663af","line":111,"in_reply_to":"6d7f4f4b_05008665","updated":"2021-03-31 07:18:59.000000000","message":"Yes, you\u0027re right that in the end universal accessibility is the point of this spec. I\u0027ll add your proposed clarification.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":9311,"name":"Tristan Cacqueray","email":"tdecacqu@redhat.com","username":"tristanC"},"change_message_id":"f11d6fca592f3768af15e5192d9ff4beed2f7c6b","unresolved":true,"context_lines":[{"line_number":121,"context_line":"makes it harder to route it into an Kubernetes/Openshift cluster from outside."},{"line_number":122,"context_line":"There is already an open review that implements this:"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* https://review.opendev.org/657102"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Security considerations"}],"source_content_type":"text/x-rst","patch_set":7,"id":"5f94adff_780e17e5","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":35},"updated":"2021-03-09 18:30:01.000000000","message":"nit: the change is already merged.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"34de52ad73a21ba9b9c74b5df2c454838498286f","unresolved":false,"context_lines":[{"line_number":121,"context_line":"makes it harder to route it into an Kubernetes/Openshift cluster from outside."},{"line_number":122,"context_line":"There is already an open review that implements this:"},{"line_number":123,"context_line":""},{"line_number":124,"context_line":"* https://review.opendev.org/657102"},{"line_number":125,"context_line":""},{"line_number":126,"context_line":""},{"line_number":127,"context_line":"Security considerations"}],"source_content_type":"text/x-rst","patch_set":7,"id":"c51dd289_bce28f00","line":124,"range":{"start_line":124,"start_character":0,"end_line":124,"end_character":35},"in_reply_to":"5f94adff_780e17e5","updated":"2021-03-31 07:19:34.000000000","message":"Done","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"2748f03c34587a9e4a0cd077bdf767cea8f11010","unresolved":false,"context_lines":[{"line_number":131,"context_line":"transferring them between different datacenters encryption would be useful."},{"line_number":132,"context_line":"So we should support optionally encrypting the finger streams using TLS with"},{"line_number":133,"context_line":"optional client auth like we do with gearman. The mechanism should also support"},{"line_number":134,"context_line":"SNI (Server name indication)."},{"line_number":135,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"79c274e9_7a5701ed","line":134,"updated":"2021-03-29 22:42:38.000000000","message":"I think that method to supply a CA file and only accept connections from certs signed by that CA, right?  If so, I agree.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":16068,"name":"Tobias Henkel","email":"tobias.henkel@bmw.de","username":"tobias.henkel"},"change_message_id":"65e95da2c8fa3998f319833260535de09b205e60","unresolved":false,"context_lines":[{"line_number":131,"context_line":"transferring them between different datacenters encryption would be useful."},{"line_number":132,"context_line":"So we should support optionally encrypting the finger streams using TLS with"},{"line_number":133,"context_line":"optional client auth like we do with gearman. The mechanism should also support"},{"line_number":134,"context_line":"SNI (Server name indication)."},{"line_number":135,"context_line":""}],"source_content_type":"text/x-rst","patch_set":7,"id":"d7e0ddd2_ffee7831","line":134,"in_reply_to":"79c274e9_7a5701ed","updated":"2021-03-31 07:18:59.000000000","message":"Yes, essentially the same we do with gearman.","commit_id":"22823f10839c7ee211f09aefa59bb237982f64b9"},{"author":{"_account_id":4146,"name":"Clark Boylan","email":"cboylan@sapwetik.org","username":"cboylan"},"change_message_id":"48b69b7dbde9ac9ac9c7685a05f54b5446332fe7","unresolved":true,"context_lines":[{"line_number":21,"context_line":"if"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"* zuul-executors are behind a NAT. In this case one would need to create a NAT"},{"line_number":24,"context_line":"  rule per executor on different ports which can become a maintenance nightmare."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* zuul-executors run in a different Kubernetes or OpenShift. In this case one"},{"line_number":27,"context_line":"  would need a Ingress/Route or NodePort per executor which also makes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"af1efd67_d528ded9","line":24,"updated":"2021-06-07 20:52:51.000000000","message":"Currently we don\u0027t have many issues with executors behind NAT because they connect to the rest of the cluster rather than having connections made to them. The proposal presented here should work just fine, but I wonder if we would be better off with having the zoned executors connect out to the finger gateways creating a connection that is happy behind NAT. Then when the fingergw looks up a stream location it can simply request it from the connection that already exists for that executor?\n\nWhere this gets complicated is we\u0027ll need to be able to run multiple streams over that single connection so tcp alone is probably insufficient?\n\nMostly thinking out loud here to point out the existing NAT bypass methodology to see if that might be preferred if workable.","commit_id":"60b5e174db040366d49f7f82ed8e37e4671048cc"},{"author":{"_account_id":1,"name":"James E. Blair","email":"jim@acmegating.com","username":"corvus"},"change_message_id":"fa884b949d0ed713978a9e38096462e5404dbec3","unresolved":false,"context_lines":[{"line_number":21,"context_line":"if"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"* zuul-executors are behind a NAT. In this case one would need to create a NAT"},{"line_number":24,"context_line":"  rule per executor on different ports which can become a maintenance nightmare."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"* zuul-executors run in a different Kubernetes or OpenShift. In this case one"},{"line_number":27,"context_line":"  would need a Ingress/Route or NodePort per executor which also makes"}],"source_content_type":"text/x-rst","patch_set":8,"id":"93324881_5b253fb2","line":24,"updated":"2021-06-07 21:00:56.000000000","message":"That sounds workable; it could use a multiplexing protocol, or the persistent connection could be used just to tell the executor to establish another connection to start a stream.\n\nThat\u0027s probably easier for the NAT case, but it\u0027s probably a coin toss for the k8s case (either way, you add a new nodeport service; just on the remote cluster in the first case, and the main cluster in the second).\n\nGiven the marginal benefit plus additional complexity, I\u0027m inclined to say let\u0027s stick with this and if the NAT issue is bothersome enough for someone to want to implement the callback idea in the future, great.","commit_id":"60b5e174db040366d49f7f82ed8e37e4671048cc"}]}