2018-02-14 1:04 GMT+01:00 R. Tyler Croy <ty...@monkeypox.org>: > (replies inline) > > On Thu, 08 Feb 2018, Surya Gaddipati wrote: > > > Hi, > > > > This is exciting new development. > > > > Couple of comments > > > > 1. Packaging supervisord with another executable is a docker anti > pattern. > > I assume any serious jenkins deployment is on a scheduler like > > swarm/kubernetes ect where supervisord is not necessary. > > > I understand the point made but I disagree with the notion that "serious" > Jenkins deployments are using Swarm or Kubernetes. The Jenkins project > itself > (for example) has been running Docker in production for over four years > now, > without a container orchestrator of any kind. This includes > https://ci.jenkins.io/. We use the garethr/docker Puppet module > (https://forge.puppet.com/garethr/docker) which itself has millions of > downloads by folks managing Docker services "the hard way." That said, we > also > have a Kubernetes environment where we're deploying newer applications > (e.g. > https://plugins.jenkins.io/) into. So I /agree/ with the point that > Kubernetes > is likely a good candidate for replacing some of the Jenkins lifecycle > management work that supervisord is currently performing, which is why I > mention Kubernetes in JEP-301 at all. However, I strongly > disagree that the market is "there" yet, I think making a container > orchestrator a requirement at this point would only inhibit adoption and > learning. I am instead erring on the side of "simple and fast" from a user > perspective, the closest we can get (IMHO) to the `java -jar jenkins.war` > experience, the easier the adoption and experimentation will be for the > user > audience I want to reach. >
I haven't found any references to supervisord in JEP pull request, neither about kubernetes - did I miss something ? Anyway I tend to agree with this comment about packaging supervisord with jenkins essential within a docker image as a bad practice. I don't think this has anything to relate to running this as plain docker or with some orchestrator, this just makes the docker image a mutable instance, which should be avoided. Without much details on where this discussion comes from I can't really tell much about alternatives. > > > > 2. Scripting should be done via yaml files, not environment variables( > > init.d/groovy). All essential plugins should be made compatible with > > configuration-as-code. > > I fully intend on using as much support as possible from the Configuration > as > Code effort which Ewelina and Nicolas are working on. I do not intend to > undertake, as part of Jenkins Essentials, patching or updating plugins in > order > to support it however. > > My order of priority for scripting Jenkins is: > > 1. Configuration as Code > 2. Groovy scripting (bleh) > 3. Hopefully very little if any scary hacks. > > > So I think we're mostly on same page here :) > > Configuration-as-Code is not ready yet to support this, but for sure we will keep an eye on this and will try to implement this use-case as well when this becomes relevant. > > > 3. Pipeline while powerful is contrary to the goal of getting new users > > started quickly. From my personal experience, very few new users have the > > appetite to learn groovy scripting to setup their builds, they just want > to > > something to run `npm test`. > > A declarative yaml file like travisci,circle ect is the *correct* > > approach here. > > I agree that this is an important goal for Jenkins as a whole to consider: > making Pipeline easier to use and be successful with. I believe those > currently > hacking on Pipeline, like abayer, would agree with that sentiment. What > *is* in > the scope of this work is making Jenkins easier to understand "out of the > box" > (https://github.com/jenkinsci/jep/tree/master/jep/300#obvious-path) which > I > believe is going to entail a number of copy-and-pasteable examples of > common > Jenkinsfiles, and other forms of built-in examples and documentation. > > Overall, thank you very much for taking the time to read JEPs and provide > feedback. The way I am interpreting your overall feedback, and please > correct > me if I'm wrong, is that the direction is promising but want to encourage > good > fundamentals on the implementation. > > > > Anywho, thanks again :) > > > > > > - R. Tyler Croy > > ------------------------------------------------------ > Code: <https://github.com/rtyler> > Chatter: <https://twitter.com/agentdero> > xmpp: rty...@jabber.org > > % gpg --keyserver keys.gnupg.net --recv-key 1426C7DC3F51E16F > ------------------------------------------------------ > > -- > 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 jenkinsci-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/jenkinsci-dev/20180214000422.hkio3rohqdgzn4pd%40blackberry. > coupleofllamas.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJz%3DqW6dSdu6%2B5VriSLbxc7ZrZ1DJP1bY5mVg%2BihUbwt2WQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
