(replies inline) On Thu, 08 Feb 2018, Jesse Glick wrote:
> https://github.com/jenkinsci/jep/blob/master/jep/301/README.adoc#plugins > > does not make sense to me. A critical benefit of this system as I > understood it was that we could deliver a complete software > package???including Jenkins core and plugins???as a unit. So why are you > treating core and plugins as distinct things? You should either > > · Package a particular version of core, and of all ???essential??? > plugins, together in a particular version of a Docker image, and have > people use a new tag of this image when they want to update anything. > That would be the normal way to manage software in Docker, though it > appears to contradict your intention of using `evergreen-client` to > perform upgrades. > > or > > · Have the image contain only the supervisor, and have it download > specific versions of Jenkins core and plugins on demand; and update > the image itself only when the supervisor changes (presumably rarely). > That also bypasses the concern noted in #security as the image would > not need to be updated merely because of a core security advisory. I apologize for the delay, I needed some time to think about and understand the points you're raising here. I think we're conceptually on the same page, and it took a bit of thinking and consultation with Kohsuke to help me fully understand your feedback here. I think the design document was unclear, and had a hidden premature optimization/assumption. I have been thus far deriving jenkins/evergreen from jenkins/jenkins simply to inherit some scripts, permissions, and other bits. This is definitely not necessary, and I agree the packaging should follow the second approach you describe, more or less: 1. Come online 2. Grab the latest, greatest, and secure-iest bits 3. Do a Jenkins \o/ I will make the JEP-301 document more clear on that. > https://github.com/jenkinsci/jep/blob/master/jep/300/README.adoc#sane-defaults > > I do not think it is wise to try to automagically detect a cloud > environment. Rather, we should offer variant images which are > preconfigured for specific environments like AWS. Or offer startup > flags etc. to select such preconfigurations, and tailor the > installation scripts for those environments to pass the right flag. I /think/ I understand where the reasoning would be for "flavors" depending on the cloud environment (for example), but to make sure I'm not making any more assumptions, would you mind expanding a bit on what your concerns are regarding a singular "all-in-one" package which can include the necessary cloud-detection auto-configuration tooling? Thanks for taking the time to review both documents and provide thoughtful feedback. I'll try to improve on my delay times, work responsibilities, you know the drillThanks for taking the time to review both documents and provide thoughtful feedback. I'll try to improve on my delay times, work responsibilities, you know the drill. *looks wearily at google calendar* I'll try to land some updates to the prototype and these design documents with your feedback tomorrow (Feb 14th). Cheers - 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/20180214000359.x72xio6o5m6qads3%40blackberry.coupleofllamas.com. For more options, visit https://groups.google.com/d/optout.
Description: PGP signature