-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Simplify setup by removing path rewrite #4653
Conversation
Codecov Report
@@ Coverage Diff @@
## master #4653 +/- ##
==========================================
- Coverage 98.05% 98.05% -0.01%
==========================================
Files 374 374
Lines 34545 34514 -31
==========================================
- Hits 33874 33843 -31
Misses 671 671
Continue to review full report at Codecov.
|
container/webui/nginx.conf
Outdated
@@ -30,7 +30,7 @@ http { | |||
proxy_set_header Connection $connection_upgrade; | |||
proxy_set_header Host $host; | |||
|
|||
rewrite /api/v1/ws/(.*) /ws/$1 break; | |||
rewrite /api/v1/ws/(.*) /api/v1/ws/$1 break; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand your reasoning in the commit message but to me this looks like /api/v1/ws/<foo>
is "rewritten" to /api/v1/ws/<foo>
meaning not rewritten at all. What am I overlooking?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, isn't the idea to be able to drop the rewrite completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not rewritten at all, that is the intended behavior (or to put it differently, the rewrite is no longer needed). I could probably delete the rewrite completely, but I am not sure if it has another side-effect, as the same style of rewrite can be found in the liveviewhandler section: rewrite /liveviewhandler/(.*) /liveviewhandler/$1 break;
.
If you are sure, it has no other functionality (like disabling other possible rewrites due to the break
) I would delete both of them to keep it consistent.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose both rewrites can be deleted then.
f1a836f
to
e13658e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good. And now to testing. Feel free to test on o3+osd as well after trying it out locally including the liveview
Hm, the only real code change is adding a route, that one was already tested during development. The liveview was only changed in the template for nginx, which is as far as I know not used on o3 nor osd. So there is not much added value here. I can probably use the setup from docker compose, where the nginx is actually used (in the load-balancer container which is not build by us). |
Well, I mean for example just apply the apache changes on o3 or osd and see that everything still works as expected. |
I can't apply the apache changes before the code change (and the code change does not require anything else, the new route will just not be used in the current setup). Or do you mean I should apply both manually (because I do not see any added value here)? |
The best approach is likely to install the packages generated by the OBS checks locally or on a staging instance and see whether it still works after restarting apache2 and the websocket server. ( |
Yes, sorry, then apply both. Or, create a separate pull request with just the code change first, have it merged, then we apply config changes afterwards |
e13658e
to
e6fdc7b
Compare
Right, I did not realize that the apache/nginx templates are actually not templates but can be used directly in some deployments. I created #4660 with only the first commit changes (adding the new route), this will follow. |
#4660 merged So, will you test it out on o3/osd or any other instance? |
@Mergifyio rebase |
There is no need to change anything in the setup as the other route (i.e. `/ws`) is also handled in the same way. On the other hand, the rewrite is unnecessary.
✅ Branch has been successfully rebased |
e6fdc7b
to
6b1b73a
Compare
Currently, this is set on osd. So far, no problems detected. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, counts as successful test for me then :)
Make websockets server understand the
/api/v1/ws
route which iscurrently rewritten by a reverse-proxy to
/ws
. This should remove theneed for having a reverse-proxy as all paths are now handled as are.
There is no need to change anything in the setup as the other route
(i.e.
/ws
) is also handled in the same way.Prerequisites: