You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Someone at a meetup lately suggested it would be cool to be able to start containers on Kubernetes so blackbox tests of containers can be done using standard test libraries.
Since this library is in an early state, it would be a great opportunity to abstract the container layer in such a way that it does not matter whether the Docker or Kubernetes APIs are used.
And we can have a new file kubernetes.go that implements that interface with a function RunPod (it should return a container just like RunContainer but via kubernetes (a pod).
Nice idea! I don't think this is a top priority btw. For example, I am using this library in a project and we use Jenkins to run tests against kubernetes but we use Docker in Docker. I am not sure about the benefits of having the ability to run pods directly. What do you think?
This is probably something we should do with the Java implementation and other forks, at the right time. Please could we discuss the general approach to tackling this?
I can't think of anything specific, but it would be good for all the implementations to be gradually moving towards convergence on feature sets rather than divergence 😄 .
On Mon, Nov 26, 2018, 22:03 Richard North ***@***.*** wrote:
This is probably something we should do with the Java implementation and
other forks, at the right time. Please could we discuss the general
approach to tackling this?
I can't think of anything specific, but it would be good for all the
implementations to be gradually moving towards convergence on feature sets
rather than divergence 😄 .
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#22 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABjgO2fZEjzfh7eycZhEmDk9WlEJcSX6ks5uzFcPgaJpZM4Yv8cC>
.
Activity
gianarb commentedon Nov 23, 2018
Yep, this is a good idea, I think we should create a Container interface with the current functions we implemented in the container like:
And we can have a new file
kubernetes.gothat implements that interface with a functionRunPod(it should return a container just likeRunContainerbut via kubernetes (a pod).Nice idea! I don't think this is a top priority btw. For example, I am using this library in a project and we use Jenkins to run tests against kubernetes but we use Docker in Docker. I am not sure about the benefits of having the ability to run pods directly. What do you think?
mraerino commentedon Nov 23, 2018
That sounds great!
mraerino commentedon Nov 25, 2018
The foundation for this has been laid in #36
rnorth commentedon Nov 26, 2018
This is probably something we should do with the Java implementation and other forks, at the right time. Please could we discuss the general approach to tackling this?
I can't think of anything specific, but it would be good for all the implementations to be gradually moving towards convergence on feature sets rather than divergence 😄 .
gianarb commentedon Nov 26, 2018
mdelapenya commentedon Aug 25, 2022
I think it makes sense to move this thread to Discussions