(replies inline) On Fri, 09 Oct 2015, Kohsuke Kawaguchi wrote:
> OK, this is probably something someone should start as a plugin. > > IIUC, you are taking the idea of the Job DSL plugin and then extending it > to the system configuration, which I think is sensible. This is highly likely *NOT* something somebody can do as a plugin (IMHO). My co-maintainer of the puppet-jenkins module gave a presentation (deck here: https://speakerdeck.com/jhoblitt/puppet-vs-jenkins-a-tale-of-types-and-providers) at PuppetConf talking about many of the hacks and pit falls of attempting to automate Jenkins. For some not-quite tl;dr action: * often times, you have to use the CLI to do anything useful with an automation tool like Puppet * The CLI doesn't expose all functionality * There is a chicken-and-egg problem with configuring security properly (do I stand the instance up, get the CLI, then enable and then make authenticated CLI calls? * In a few cases the Jenkins UI would exercise one code path, the CLI would exercise another, actually resulting in inconsistent results! >_< (obviously these are bugs). All of these, to me, say that there are fundamental flaws with how Jenkins is structured from a systems administration standpoint. The most duh/obvious one is that data is not cleanly separated from configuration making it very difficult to automate. I don't need to automate the data part (shove it in a DB for all I care ;)) but in Puppet I've got tons of well-defined, easily tested patterns for generating configuration files. Anyways, I'm definitely in the same camp as Baptiste but I don't really have good suggestions on solutions right now :/ > 2015-10-07 13:05 GMT-07:00 Baptiste Mathus <[email protected]>: > > > Another idea I'll dump here. it's still a bit fluffy, but anyway. > > > > I think that with the config-management/devops trend, it would be a good > > thing that Jenkins can really be configured from scratch through (most > > simple possible) CLI/API calls. It's currently possible but requires a > > quite high-level knowledge of Jenkins internals to achieve (groovy scripts, > > and so on). > > > > For the jobs part, IMO things like the Job DSL Plugin to handle job > > versioning and durable management are great. And that would be great to > > have an equivalent for the instance. > > Something like a high-level language (say DSL) to describe the server > > configuration.config itself. > > > > Maybe this is not something necessarily breaking things, hence not > > necessarily related to 2.0, but perhaps some contract/interface could be > > introduced in plugins to kind of standardize that discovery and be able to > > offer a standard API to configure Jenkins? > > > > The area to handle off the top of my head: > > * Core configuration (slaves, tools...) > > * Plugins to install (see also > > https://github.com/jenkinsci/docker/blob/master/README.md#installing-more-tools > > for reference/example) > > * Plugins config > > * Jobs > > > > My 2 cents > > > > 2015-10-07 19:39 GMT+02:00 Kohsuke Kawaguchi <[email protected]>: > > > >> Right, I remember looking at DotCi and thinking that the way it moved the > >> storage to mongodb points toward an abstraction we can build. > >> > >> Similar hook already exists for artifacts, and then we can provide > >> auxiliary BLOB store for plugins that write random bits of data under > >> builds, jobs, etc. > >> > >> Over time we can move things one by one to the BLOB store like that, then > >> at that point we have filesystem free Jenkins. > >> > >> > >> 2015-10-06 11:18 GMT-07:00 Surya Gaddipati <[email protected]>: > >> > >>> Regarding backend solution. We use DotCi and store all builds/logs in > >>> mongodb.( Still experimenting how to properly store logs in the db, but we > >>> have it working on staging). > >>> > >>> The only things on disks are plugins and folder config.xml ( because of > >>> this issue https://github.com/jenkinsci/jenkins/pull/1762, jenkins > >>> deletes anything not on disk from memory ). I need to spend time to fix > >>> the > >>> issue in jenkins properly. > >>> > >>> > >>> Once that is done. We can have things like, deploying on heroku , true > >>> load balancing with multiple masters. > >>> > >>> One more thing that is preventing from from jenkins from being used in > >>> any serious installations is heavily thread locked Queue implementation. > >>> We > >>> are having to do strange workarounds with our jenkins because it > >>> threadlocks under even medium loads ( I saw this mentioned in google's > >>> slides for JUC too, curious what their solution was ) . > >>> > >>> An extension point for queue would be great so we can store queue in > >>> redis or something. > >>> > >>> > >>> Surya > >>> > >>> -- > >>> 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/9d9e1968-b7c7-4296-899c-f2b05f10ac6a%40googlegroups.com > >>> <https://groups.google.com/d/msgid/jenkinsci-dev/9d9e1968-b7c7-4296-899c-f2b05f10ac6a%40googlegroups.com?utm_medium=email&utm_source=footer> > >>> . > >>> > >>> For more options, visit https://groups.google.com/d/optout. > >>> > >> > >> > >> > >> -- > >> Kohsuke Kawaguchi > >> > >> -- > >> 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/CAN4CQ4zpgWrGyuE0KkfKejMxSVuXNgabdL6K5XTnZRo5k1uAhg%40mail.gmail.com > >> <https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4zpgWrGyuE0KkfKejMxSVuXNgabdL6K5XTnZRo5k1uAhg%40mail.gmail.com?utm_medium=email&utm_source=footer> > >> . > >> > >> For more options, visit https://groups.google.com/d/optout. > >> > > > > > > > > -- > > Baptiste <Batmat> MATHUS - http://batmat.net > > Sauvez un arbre, > > Mangez un castor ! > > > > -- > > 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/CANWgJS4sQeMo4pdpfgyvTyJ9z6i%3DmSWQG9Bh_%2BOA%3DswX2jYMaw%40mail.gmail.com > > <https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS4sQeMo4pdpfgyvTyJ9z6i%3DmSWQG9Bh_%2BOA%3DswX2jYMaw%40mail.gmail.com?utm_medium=email&utm_source=footer> > > . > > > > For more options, visit https://groups.google.com/d/optout. > > > > > > -- > Kohsuke Kawaguchi > > -- > 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/CAN4CQ4yK2pDoHY-5KmHssYH0XPxh-PbnjrXJDN-W3zuXa5pGvQ%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. - R. Tyler Croy ------------------------------------------------------ Code: <https://github.com/rtyler> Chatter: <https://twitter.com/agentdero> % gpg --keyserver keys.gnupg.net --recv-key 3F51E16F ------------------------------------------------------ -- 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/20151014040542.GE2450%40blackberry.coupleofllamas.com. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Digital signature
