Re: Perforce proxy servers
Christian-- Sorry if I wasn't clear; yes the problem is with post-review's attempt to automatically determine the repository. It looks like the REPOSITORY setting should take care of this issue for us. Now time for me to RTFM... Thanks. -Chris On Jul 25, 5:05 pm, Christian Hammond chip...@chipx86.com wrote: Hi Chris, You may have said this already and I may have missed it, but is the core problem with the various proxy names that post-review's unable to find the correct repository to patch? If so, you can reference repositories by name instead of by path: http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/#r... Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Mon, Jul 25, 2011 at 12:00 PM, chrisn ch...@newbold.org wrote: Yes, thanks David and Christian for the tips on configuration that enabled us to finally track down the mis-configuration. The final, working configuration has the 'p4 info' name in the repository Path and the proxy in the Mirror Path. We still have somewhat of an issue with proxies, however. When the server to which the proxy directs clients changes, Review Board stops working until we manually update the configuration with the new value from 'p4 info'. For example, we had things working at the end of last week, but a weekend fail-over of the Perforce server changed the result of 'p4 info' and everything stopped working again. -Chris On Jul 22, 9:47 am, SCFrench sc...@mathworks.com wrote: I've been working with Chris on this issue. We seem to have it working now. There appears to have been two issues that were combining to make this harder than usual to fix. First, the diagnostics on the call to p4 in get_file in perforce.py are relying on the exit status to indicate that something went wrong. However, as I found here: http://forums.perforce.com/index.php?/topic/682-noob-question-changel..., the exit status of p4 is almost always 0. When I finally figured out what p4 command was being run by get_file, and ran it manually, I got this failure (edited slightly to remove private information): % p4 -p perforce-xx-xxx.mathworks.com:1666 -u cnxx print -q '//xxx/ xxx/queue/matlab/src/m_interpreter/mi_interpreter/clear.cpp#17' //xxx/xxx/queue/matlab/src/m_interpreter/mi_interpreter/clear.cpp#17 - no permission for operation on file(s). % echo $? 0 The link above discusses some ways to improve error checking on scripted p4 invocations, by using the -s option. Not sure if that will work for Review Board, but I thought I'd pass it along. The second issue was that once the file clear.cpp had been incorrectly retrieved, the bad (empty) version got cached, and subsequent attempts to fix the problem by changing the name of the repository at the admin site apparently were effective no-ops because that information is ignored if the file is already cached locally. Restarting memcached cleared the cache and allowed us to make progress on the first issue. Hope this information helps to make Review Board even better! Scott On Jul 20, 1:57 pm, Christian Hammond chip...@chipx86.com wrote: Hi Chris, The Path field should probably point to the proxy, and Mirror Path should point to 'p4 info'. It's a bit confusing (the Mirror Path name exists for legacy reasons) and I want to clean that up, but start with that. Basically, we'll always communicate through Path, but we check both Path and Mirror Path when using post-review. We can't log the commands because, with the exception of one case, we're not calling out to p4. We're instead using the Python bindings for the library that is talking directly to the server. Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Wed, Jul 20, 2011 at 8:29 AM, chrisn ch...@newbold.org wrote: I just filedhttp:// code.google.com/p/reviewboard/issues/detail?id=2182 to describe an issue with ReviewBoard and Perforce proxy servers that is effectively blocking us from using ReviewBoard. I'd appreciate any thoughts or BTDT advice about how I might be able to work around the problem. Thanks. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know athttp://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know athttp://www.reviewboard.org/users
Re: Perforce proxy servers
Yes, thanks David and Christian for the tips on configuration that enabled us to finally track down the mis-configuration. The final, working configuration has the 'p4 info' name in the repository Path and the proxy in the Mirror Path. We still have somewhat of an issue with proxies, however. When the server to which the proxy directs clients changes, Review Board stops working until we manually update the configuration with the new value from 'p4 info'. For example, we had things working at the end of last week, but a weekend fail-over of the Perforce server changed the result of 'p4 info' and everything stopped working again. -Chris On Jul 22, 9:47 am, SCFrench sc...@mathworks.com wrote: I've been working with Chris on this issue. We seem to have it working now. There appears to have been two issues that were combining to make this harder than usual to fix. First, the diagnostics on the call to p4 in get_file in perforce.py are relying on the exit status to indicate that something went wrong. However, as I found here:http://forums.perforce.com/index.php?/topic/682-noob-question-changel..., the exit status of p4 is almost always 0. When I finally figured out what p4 command was being run by get_file, and ran it manually, I got this failure (edited slightly to remove private information): % p4 -p perforce-xx-xxx.mathworks.com:1666 -u cnxx print -q '//xxx/ xxx/queue/matlab/src/m_interpreter/mi_interpreter/clear.cpp#17' //xxx/xxx/queue/matlab/src/m_interpreter/mi_interpreter/clear.cpp#17 - no permission for operation on file(s). % echo $? 0 The link above discusses some ways to improve error checking on scripted p4 invocations, by using the -s option. Not sure if that will work for Review Board, but I thought I'd pass it along. The second issue was that once the file clear.cpp had been incorrectly retrieved, the bad (empty) version got cached, and subsequent attempts to fix the problem by changing the name of the repository at the admin site apparently were effective no-ops because that information is ignored if the file is already cached locally. Restarting memcached cleared the cache and allowed us to make progress on the first issue. Hope this information helps to make Review Board even better! Scott On Jul 20, 1:57 pm, Christian Hammond chip...@chipx86.com wrote: Hi Chris, The Path field should probably point to the proxy, and Mirror Path should point to 'p4 info'. It's a bit confusing (the Mirror Path name exists for legacy reasons) and I want to clean that up, but start with that. Basically, we'll always communicate through Path, but we check both Path and Mirror Path when using post-review. We can't log the commands because, with the exception of one case, we're not calling out to p4. We're instead using the Python bindings for the library that is talking directly to the server. Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Wed, Jul 20, 2011 at 8:29 AM, chrisn ch...@newbold.org wrote: I just filedhttp://code.google.com/p/reviewboard/issues/detail?id=2182 to describe an issue with ReviewBoard and Perforce proxy servers that is effectively blocking us from using ReviewBoard. I'd appreciate any thoughts or BTDT advice about how I might be able to work around the problem. Thanks. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know athttp://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Re: Perforce proxy servers
Hi Chris, You may have said this already and I may have missed it, but is the core problem with the various proxy names that post-review's unable to find the correct repository to patch? If so, you can reference repositories by name instead of by path: http://www.reviewboard.org/docs/manual/dev/users/tools/post-review/#repository Christian -- Christian Hammond - chip...@chipx86.com Review Board - http://www.reviewboard.org VMware, Inc. - http://www.vmware.com On Mon, Jul 25, 2011 at 12:00 PM, chrisn ch...@newbold.org wrote: Yes, thanks David and Christian for the tips on configuration that enabled us to finally track down the mis-configuration. The final, working configuration has the 'p4 info' name in the repository Path and the proxy in the Mirror Path. We still have somewhat of an issue with proxies, however. When the server to which the proxy directs clients changes, Review Board stops working until we manually update the configuration with the new value from 'p4 info'. For example, we had things working at the end of last week, but a weekend fail-over of the Perforce server changed the result of 'p4 info' and everything stopped working again. -Chris On Jul 22, 9:47 am, SCFrench sc...@mathworks.com wrote: I've been working with Chris on this issue. We seem to have it working now. There appears to have been two issues that were combining to make this harder than usual to fix. First, the diagnostics on the call to p4 in get_file in perforce.py are relying on the exit status to indicate that something went wrong. However, as I found here: http://forums.perforce.com/index.php?/topic/682-noob-question-changel..., the exit status of p4 is almost always 0. When I finally figured out what p4 command was being run by get_file, and ran it manually, I got this failure (edited slightly to remove private information): % p4 -p perforce-xx-xxx.mathworks.com:1666 -u cnxx print -q '//xxx/ xxx/queue/matlab/src/m_interpreter/mi_interpreter/clear.cpp#17' //xxx/xxx/queue/matlab/src/m_interpreter/mi_interpreter/clear.cpp#17 - no permission for operation on file(s). % echo $? 0 The link above discusses some ways to improve error checking on scripted p4 invocations, by using the -s option. Not sure if that will work for Review Board, but I thought I'd pass it along. The second issue was that once the file clear.cpp had been incorrectly retrieved, the bad (empty) version got cached, and subsequent attempts to fix the problem by changing the name of the repository at the admin site apparently were effective no-ops because that information is ignored if the file is already cached locally. Restarting memcached cleared the cache and allowed us to make progress on the first issue. Hope this information helps to make Review Board even better! Scott On Jul 20, 1:57 pm, Christian Hammond chip...@chipx86.com wrote: Hi Chris, The Path field should probably point to the proxy, and Mirror Path should point to 'p4 info'. It's a bit confusing (the Mirror Path name exists for legacy reasons) and I want to clean that up, but start with that. Basically, we'll always communicate through Path, but we check both Path and Mirror Path when using post-review. We can't log the commands because, with the exception of one case, we're not calling out to p4. We're instead using the Python bindings for the library that is talking directly to the server. Christian -- Christian Hammond - chip...@chipx86.com Review Board -http://www.reviewboard.org VMware, Inc. -http://www.vmware.com On Wed, Jul 20, 2011 at 8:29 AM, chrisn ch...@newbold.org wrote: I just filedhttp:// code.google.com/p/reviewboard/issues/detail?id=2182 to describe an issue with ReviewBoard and Perforce proxy servers that is effectively blocking us from using ReviewBoard. I'd appreciate any thoughts or BTDT advice about how I might be able to work around the problem. Thanks. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know athttp://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http
RE: Review Board with Perforce proxy servers
I can't give a full response to everything here, but if you're using post-review (likely) then the P4PORT env variable is effectively ignored. Instead, post-review runs p4 info and pulls the port information from the Server address: server.domain.com:1666 line. It then calls gethostbyaddr() on the result and compares the results to the values on the reviewboard server's repository list. The reviewboard server contacts the perforce server using the locations defined in the reviewboard server's repository list and dynamically generates the diff content every time the diff is viewed. So, how to optimize this for your users? I don't know, but I thought I could shed some light on how it's working to help figure that out :) Dana Lacoste -Original Message- From: reviewboard@googlegroups.com [mailto:reviewbo...@googlegroups.com] On Behalf Of Jason Alday Sent: Wednesday, October 20, 2010 4:16 PM To: reviewboard Subject: Review Board with Perforce proxy servers Hi, We've recently starting using Review Board for our team but we are spread out across several sites in the US. Each site has it's own P4 proxy server that people on that site use for their P4 activity. Behind the scenes I understand these proxies phone home to master P4 server (which is actually outside the US). The Review Board server is actually located in one of these remote sites inside the US, far from the master P4 server. From what we can tell, when the user is using post-review the p4Info that comes back appears to be the master server that is outside the US (even though their P4PORT env variable is set to their local proxy) The repositories for Review Board are also set to the server outside the US. It would be ideal if the post-review diff was generated based on the users local P4 proxy as that would be the fastest. Then it would be ideal if the Review Board server used the local proxy for it's location. Is this possible? It's not clear to me how much P4 server contacting the Review Board server does. When the user clicks on View Diff in Review Board, does that result in the server contacting the P4 server for any info or is all of this info stored locally in the Review Board's database from the submission time? Thanks, Jason. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
Review Board with Perforce proxy servers
Hi, We've recently starting using Review Board for our team but we are spread out across several sites in the US. Each site has it's own P4 proxy server that people on that site use for their P4 activity. Behind the scenes I understand these proxies phone home to master P4 server (which is actually outside the US). The Review Board server is actually located in one of these remote sites inside the US, far from the master P4 server. From what we can tell, when the user is using post-review the p4Info that comes back appears to be the master server that is outside the US (even though their P4PORT env variable is set to their local proxy) The repositories for Review Board are also set to the server outside the US. It would be ideal if the post-review diff was generated based on the users local P4 proxy as that would be the fastest. Then it would be ideal if the Review Board server used the local proxy for it's location. Is this possible? It's not clear to me how much P4 server contacting the Review Board server does. When the user clicks on View Diff in Review Board, does that result in the server contacting the P4 server for any info or is all of this info stored locally in the Review Board's database from the submission time? Thanks, Jason. -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~--~~~~--~~--~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en
