Replies: 3 comments 8 replies
-
|
I'm really interested in those potential, more complex use cases without DNS or hostnames, to have an even wider overview of the problem we want to resolve. As I said in #587 (comment), we are open to the addition once we understand them better. I have to admit that we (I) probably merged #394 without as much context as the one I have know (joined as a full time maintainer in August), and in that sense, I can share here that Testcontainers (in any available language) is not a generic Docker client that needs to expose all methods and config params of the underlying Docker client. In any case, we'd like to cooperate with you in improving the setup of your tests, and that could lead to merging #587 into the code |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the example @oktalz. In this case, what would happen if you start to parallelize tests (either locally or on CI) and you have conflicts with reusing the same IP address? In Testcontainers for Java, we have a mechanism to fall back to the That's why I would advocate for giving better access to modifying the container creation request through a different mechanism, that is not part of the top-level Testcontainers API. |
Beta Was this translation helpful? Give feedback.
-
|
@kiview I don't use same IP ranges in all tests :) that would be pointless.
I understand that it is opinionated, that is totally fine.
my first PR solution even had dynamic example (create subset dynamically, then you are safe regardless what you do), but for the purpose of it I simplified it to not test something that is out of scope of a that PR.
yes, something else might be a better option, however, this can be done without any impact also with testcontainers, but that is my view :) |
Beta Was this translation helpful? Give feedback.
-
|
@oktalz we had a deep chat on this today, and I come with good news. We are going to implement a callback mechanism at the container request level which will provide the very same capabilities you are proposing in your PR. But why in a callback instead of directly in the container request? The container request represents the public API that anybody will use. This is what I call layer1. Having the IP exposed there will open the gate to possible mistakes for a misuse of the public API (layer1). On the contrary, adding the IP settings as a function that modifies the request in a separate layer (layer2), will make it possible to use layer1 in a simple manner and at the same time, more advanced users will have the ability to use layer2 to provider a more advanced configuration for their containers. We will eventually be transitioning advanced capabilities from the container request (CapAdd/CapDrop, Shmsize, etc) to the layer2, hopefully in a non-breaking manner. Of course documentation will take an important place here. I wanted to let you know, as we value your time creating this discussion. |
Beta Was this translation helpful? Give feedback.
-
|
callback or direct access is not really important, but Easier maintenance is certainly a good thing, especially due to project having more and more dependencies ( even some weird replace directives in library :), but that is not relevant here ) |
Beta Was this translation helpful? Give feedback.
-
|
Indeed. Because we are coupled to Docker, and they have the same replace directives until they release 22.06 (see latest release notes and #629 about that), we were forced to push those directives too. Hopefully resolved soon |
Beta Was this translation helpful? Give feedback.
-
|
Hi @oktalz just to let you know, we released 0.18.0 yesterday, which comes with an interesting feature: it allows customising certain, internal Docker types via 3 modifier functions in the container request: https://golang.testcontainers.org/features/creating_container/#advanced-settings Please let us know if this ability helps you out under the specific conditions of your test suite. I'd like to personally thank you for opening this discussion, which led to this change, making us to much better understand the real needs under the request. 🙇 Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
@oktalz ah! I almost forgot it... We removed the replace directives as Docker folks improved their dependencies too |
Beta Was this translation helpful? Give feedback.
-
|
Thx, I'll give it a chance. |
Beta Was this translation helpful? Give feedback.
-
|
Given this feature has been implemented with the request modifiers, I'm closing this issue as Done. Thanks for opening this discussion, which led to a feature request! |
Beta Was this translation helpful? Give feedback.
-
there is already option to set custom IPAM setting to a network seen here [network.go#L40)](https://github.com/testcontainers/testcontainers-go/blob/main/network.go#L40
Could we add similar option to container itself ?
underline code-base already allows setting that options as it can be seen github.com/docker/docker/api/types/network
so it is just a matter of passing those values to it.
since IPAMConfig is a pointer, by default is nil, this feature can be added without changing of behavior of a library
potential use cases are many, but with using some protocols that can't use DNS, of hostnames this is very much welcomed.
in more complex tests where each instance must know/need to have list of all nodes/containers prior to run this would also help.
currently only way of doing that is run all containers, fetch the IPs, stop all containers, create a valid configuration for services, and then start containers again with known IP addresses.
option to set IP address in advance would greatly speed up test in that particular use case
you can also do that in docker compose for example, but I would like to see more Go native way and not run docker compose up and then cleanup after the test is run (so, by using this library and not with external tools)
Beta Was this translation helpful? Give feedback.
All reactions