(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.

> 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 :)

> 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 
For more options, visit https://groups.google.com/d/optout.

Attachment: signature.asc
Description: PGP signature

Reply via email to