2018-02-14 1:04 GMT+01:00 R. Tyler Croy <[email protected]>: > (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: [email protected] > > % 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 [email protected]. > 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 [email protected]. 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.
