On Tuesday, November 17, 2015 at 7:28:00 PM UTC+3, Jesse Glick wrote: > > On Mon, Nov 16, 2015 at 10:02 PM, kmbulebu <[email protected] > <javascript:>> wrote: > > I believe the real horse race is between the > > underlying docker libraries. In the end, we'll likely have a clear > winner, > > and can standardize a group of plugins around that. Perhaps > docker-commons > > becomes that focal point, and we have smaller plugins that deliver > slaves, > > build steps, workflow DSL, etc. > > Seems reasonable to me to have smaller plugins with focused features, > and a little competition. I would not object to hosting as is, > provided that plugin wikis clearly link to alternatives. > > IIUC the main differences between your plugin and the `Cloud` portion > of the `docker` plugin are > > · Different client libraries. No clear winner yet. > I created small thread between docker-java and docker-client to unify efforts, but obviously it will be long time action and probably will have no results. Both libraries missing different things, but technically docker-client doesn't support callbacks for long running commands.
· Slave launcher: yours uses JNLP; `docker` plugin currently ships > SSH, has JNLP support in code but disabled. > It was disabled because of lack of integration tests, ssh launching stabilisation was very hard and i didn't want to have broken instances with one more untested launcher. Those PR that tried enable JNLP was not exactly how it was planned to work from design view point. > > If you can later reach consensus with the `docker` plugin devs on the > approach to take for a general-purpose Docker cloud provider, it > should be possible to unify code into a new plugin release. Automatic > migration of user settings will be a bit trickier but is possible. > As soon as @magnayn likes "master development" without test cases he will of course merge any changes. So you are free to submit any PRs to docker-plugin now. > > By the way your comparison chart neglected to mention > > https://github.com/ndeloof/docker-slaves-plugin > > which is a novel approach that I think is very promising. > Very promising thing will be finally implement normal Cloud API in core (or in plugin but provide normal extension points) because docker is not only the single cloud provider. PS i'm co-maintainer of docker-java atm and working on one more docker cloud plugin for jenkins which from my viewpoint will have the best implementation of currently possible state. TLS support in docker-plugin is also possible (or even already works) because docker-java resolves system variables for connection builder (though there is no right implementation for this field). PPS From tech viewpoint i see that "ephemeral cloud" has queue lock issues and shading. But if this plugin solves user issue, then it should be hosted and allow people experiment on it. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/d10a18f3-1c8c-4398-aecb-b9e474818ff4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
