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

Attachment: signature.asc
Description: PGP signature

Reply via email to