So, to clarify: *I would like to keep this thread dedicated to the pros and cons to either write a `jenkins-module` as advised by Jesse, or a Jenkins plugin to host the classes that this will require*, whatever the implementation paths we choose. For instance, I think I'll also need to write a JSONFormatter for easier consumption/parsing by the evergreen-client, so we definitely need a place to put those.
I'll start or fork a dedicated thread to discuss implementations choices. Or someone feel free to do it if having any feedback to provide. 2018-04-03 11:30 GMT+02:00 Baptiste Mathus <m...@batmat.net>: > > > 2018-04-02 15:27 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>: > >> On Fri, Mar 30, 2018 at 11:15 AM, Baptiste Mathus <m...@batmat.net> wrote: >> > SocketHandler is unusable for real life IMO: any loss of connection >> will not be reconnected. >> > So we need to develop something that *will* reconnect and be more >> robust for our usage. >> >> You seem to be assuming that you must stream logs to the >> `evergreen-client` using a local TCP socket, which is not obvious to >> me. There are other options, such as a text file or set of files in >> the `var` directory, which would have different robustness >> characteristics. >> > > Yes, sorry. I should have clarified upfront why I didn't put that here to > save iterations for everyone. > > So the design/thought process has been the following: writing to rotating > log files was my first idea, we would be able to have a fixed disk usage > for logs using java.util.logging.FileHandler.limit > and java.util.logging.FileHandler.count for instance OOTB. > But Tyler was "not super keen on hitting the file system for completely > ephemeral data passed between evergreen-client and jenkins", and asked > asked if we couldn't use a unix socket instead. > > After a quick search, I concluded that though technically feasible, using > unix sockets from Java was not the right thing to do (IIUC, it requires > using JNI/JNR, which I still have scars from JNI usage in 2003 :)). > > >> > means we add that component in the core, or at least in some jar added >> > to its classpath or something (?). Less common usage pattern than a >> plugin, >> > could it lead to issues? >> >> I think what you are looking for is `jenkins-module` packaging: akin >> to a plugin, but bundled in `jenkins.war!/WEB-INF/lib/*.jar` so that >> its classes are available in the same loader as `jenkins-core.jar`. If >> you are patching `jenkinsci/jenkins/war/pom.xml` for this anyway, this >> is trivial (just add it to the list of modules); otherwise, there is a >> mojo in `maven-hpi-plugin` to create a customized Jenkins WAR file >> based on a stock `org.jenkins-ci.main:jenkins-war` release with some >> additions and modifications, which would be appropriate for a >> distribution like Essentials / Evergreen anyway. >> > > Right. TBH though I fully agree with your last statement for the next > months, I wonder how much this is *immediately* desirable for the next > _weeks_. > Because that would mean to me we right away need to setup a more involved > release pipeline on the Jenkins Essentials WAR itself, when we're currently > still working hard on making it just usable (and switching to another WAR > flavour _could_ be done later). > > > >> >> > we need to use a bit more convoluted way to get >> > the early logs from the startup reading Jenkins.logRecords before being >> able >> > to setup our own JUL Handler >> >> This is pretty trivial, no? You register your handler, and at that >> moment you also copy everything in `Jenkins.logRecords`—done. >> Obviously if there were more than ~256 messages prior to this plugin’s >> initialization, you will miss some of the earlier ones, but in such a >> case it should be obvious that something is very wrong. >> > > Yes. It is trivial. Hence why I said "bit more convoluted", and not "more > complex" :-). > And IMO you summarized well the convolution again in the 5 lines above > again, which makes it eligible as one of the cons of this strategy :). > > >> >> > we'll miss a few very early startup logs which are, IIUC, sent before >> the >> > core sets up the RingBufferLogHandler to populate Jenkins.logRecords. >> >> Sure, but if there were any `WARNING`+ messages printed before that >> point very early in Jenkins startup, it likely that the instance is >> more or less hosed and you will notice this from a standard HTTP >> status check anyway. >> > > That is right. And for first iterations we plan anyway indeed to only > check Jenkins health from an HTTP call, so we'd detect it. > But that is still just another (small) disadvantage of this solution. > > > >> >> -- >> 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/ms >> gid/jenkinsci-dev/CANfRfr2mbREAVyteyaC0KDNKw33fNdzCBZK14RN37 >> 4QYUAnGTQ%40mail.gmail.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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANWgJS5E_rhA0tBGZJU_mZU%2BkPa8wpkU4cqSUGNNsG7arrq_Qg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
