Hello, (Changing the subject also because I don't think it's strictly necessary for people to read the previous thread to be able to provide help/feedback here).
I've started working on https://issues.jenkins-ci.org/browse/JENKINS-49805, and the tests I've done so far led me to see two possible ways out for this design. Now we are able to catch the logs we want, we started to discuss how we would ship them to the backend. For many reasons (the main one being the client is the one securely connected to the backend), it makes sense to push those logs to the [local] evergreen-client. The most obvious way for it is to push those logs using a SocketHandler. The thing is: 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. I see two possible ways for this: == Adding that improved SocketHandler into the core Pros: * we can use a simple logging.properties file and configure the logging exclusively from there. No plugin or so involved. * And we get early Jenkins startup logs without without stunt. Cons: 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? (not saying we couldn't make it work. I'm more talking about "is it worth taking this path") == Adding that SocketHandler into an "Essentials Jenkins plugin" Pros: * maybe a more usual way to change the features Jenkins offers (keeping the core leaner and leaner) * maybe slightly more usual too to upgrade (though Essentials is designed also to make the core upgrades far more common than it is now too, granted) Cons: * I have a PoC for this, but 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 * we'll miss a few very early startup logs which are, IIUC, sent before the core sets up the RingBufferLogHandler to populate Jenkins.logRecords. WDYT? Any feedback/opinion on the preferred way forward? I've started writing the JEP for this, and that's why I'm asking: I want to make sure to get everything possible with pros & cons of both strategies to move forward. Thanks! 2018-03-01 1:17 GMT+01:00 R. Tyler Croy <ty...@monkeypox.org>: > > I just wanted to make sure I shared an update on this thread. I have filed > the > following ticket (https://issues.jenkins-ci.org/browse/JENKINS-49805) to > capture some of the prototyping work necessary here. > > I expect we'll have a draft JEP coming up after the prototyping work is > done. > > > Thanks for the ideas and feedback everybody! > > > > 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/ms > gid/jenkinsci-dev/20180301001723.rhhvyfhwpxthmsnx% > 40blackberry.coupleofllamas.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/CANWgJS6_Z9hVLWch6%3DuDDOYXAOeSrvAsPF9NDzh3LxJ%3D_WC17g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
