-
Notifications
You must be signed in to change notification settings - Fork 212
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
Add scheme option to bind to both HTTP and HTTPS #1215
Conversation
Interesting. Can you share more details on that use case? Like, why you need the server to bind on both? |
@fsouza, we have an internal testing setup that is running with http because it was easier to setup. We want to use gsutil in that setup, and it supports https only. |
main.go
Outdated
if cfg.Scheme != "both" { | ||
startServer(logger, &cfg, cfg.Scheme) | ||
} else { | ||
startServer(logger, &cfg, "http") | ||
startServer(logger, &cfg, "https") | ||
} |
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.
Can we setup two listeners that point to the same server instance? I feel like that would make the most sense.
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.
@fsouza , I can do that, although I am not sure there is a big penalty when having two servers.
Started implementing but ran into lister code inside NewServerWithOptions
which complicates a bit the transition to 2 listeners with a single server:
https://github.com/ramir-savvy/fake-gcs-server/blob/ea0ba662c5381c1317c13151f231e361cb7e51e9/fakestorage/server.go#L163
options.NoListener
is set to true
by default and only set to false
in the tests.
Can you clarify its use?
If the NewServerWithOptions
function just returned in that line instead of starting listeners for tests it would be easier.
Or maybe keep it as it is and ignore that in the server run because it is relevant just for tests?
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.
although I am not sure there is a big penalty when having two servers
I was under the assumption that you wanted both servers to serve the same underlying buckets and objects? Without that, the memory backend will not have the same underlying objects, and I'd prefer that we don't diverge the capabilities of the backends here.
We can also decouple the backend from the server (i.e. support taking a backend instance in the server constructor), and in that case having two servers won't matter (similar to how the grpc server takes the backend instance).
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.
@fsouza , you are right of course, I didn't take that into account.
I have pushed a commit that changes the code to have 2 listeners and a single server.
I looked at decoupling the backend from the server but it didn't seem to be so trivial.
Let me know what you think. Thanks
@ramir-savvy gotcha, thanks for clarifying! |
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.
Can you take a look at the test failure? Thanks!
b8b3dbd
to
d708fee
Compare
Apologies @fsouza ! |
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.
Thank you! It looks like some examples are failing due to the comment I left about existing usages of -scheme http -port <something>
.
Let me know what you think!
internal/config/config.go
Outdated
port := c.Port | ||
if scheme == "http" { | ||
port = c.PortHTTP | ||
} |
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.
Won't this be a breaking change? Like, if I'm currently using fake-gcs-server like this:
fake-gcs-server -scheme http -port 8080
The server will now start on port 8000
instead of 8080
.
I know this is fairly complicated, but could we make it so:
port
andport-http
no longer have a default at the flag definition. We'll handle it ourselves- if the user specifies
-scheme http
and-port
, we use that port (keep current behavior) - if the user specifies just
-scheme http
, we use the default-port
(keep current behavior) - if the user specifies just
-scheme both
, we'll use the default-port
and-port-http
- if the user doesn't provide any flags, we'll use the default
-port
and-scheme https
Perhaps we can turn each of the 5 examples in test cases for the function/core logic that handles this.
We may be able to implement this custom logic with a custom implementation of flag.Value, but it sounds tricky as it'd need to be aware of the value of another flag. The biggest advantage of using a custom flag.Value is differentiating between the user not providing the flag and setting it to 0
(I'm not super concerned about that though - right now if the user sets it to 0
, we start the server in a random port, but never print that port to the user, so who cares? heh)
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.
You are correct. I overlooked the http port in my last fix and broke the behavior, that I previously maintained. Thanks for catching that!
I implemented the port
and port-http
without defaults in the flag
API but set it myself in the code if their value is 0. As you suggest, I also think that no one uses it today with port 0, so I don't think it is a breaking change, so I didn't implement the custom flag.Value
.
I have an idea of how to implement it, maybe using flag.Visit
, and I will do it if you think it is needed.
Please let me know.
Implemented after all using flag.Visit
- so the port 0 can be set by a user as before.
Will work on adding the test cases soon.
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.
@fsouza
Added unit tests to cover the examples you listed and few more to be on the safe side. The tests found an issue with both
scheme in the cfg.externalURL
config - fixed.
Added 2 more runs to the github action to cover both
scheme with default and non-default ports.
Let me know what you think. Thanks
Co-authored-by: fsouza <108725+fsouza@users.noreply.github.com>
b6836e3
to
8614c04
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.
Thank you!
@fsouza, I just learned that after all there is a breaking change with this PR. |
In 1.47 the default port changed to 8000 if http is used. This also sets it explicitly should it ever change again. See fsouza/fake-gcs-server#1215 .
In 1.47 the default port changed to 8000 if http is used. This also sets it explicitly should it ever change again. See fsouza/fake-gcs-server#1215 .
In 1.47 the default port changed to 8000 if http is used. This also sets it explicitly should it ever change again. See fsouza/fake-gcs-server#1215 .
13738: fix(ci): configure fake gcs server port r=oleschoenburg a=megglos ## Description In 1.47 the default port changed to 8000 if http is used. This also sets it explicitly should it ever change again. See fsouza/fake-gcs-server#1215 . Co-authored-by: Meggle (Sebastian Bathke) <sebastian.bathke@camunda.com>
In 1.47 the default port changed to 8000 if http is used. This also sets it explicitly should it ever change again. See fsouza/fake-gcs-server#1215 . (cherry picked from commit eebcda3)
We have a use case where we need the same server to run in both HTTP and HTTPS.
This PR starts two servers when needed (the default single HTTPS server is kept).
It is controlled by adding/changing the following command line arguments:
scheme
argument can now get the valueboth
port-http
argument, defaults to8080
, is used to bind HTTP port only whenscheme
is set toboth
. To clarify: to maintain backwards compatibility, when thescheme
is set tohttp
, this argument isn't used. The previousport
will be used to bind HTTPS.Added/updated tests
Updated README