OK, I'll make sure to have them recorded. You are right about release being another SPoF that needs addressing. A part of the problem is the need to hook up Windows & OSX slaves (the trust issue associated with it and all), and a part of the problem is the handling of code signing private keys.
2015-02-16 11:57 GMT-08:00 Richard Bywater <[email protected]>: > Sounds like a great idea - even if the term "ops lead" isn't used then it > would be good for one (or two?) people to drive things a bit as otherwise > its easy for people to sit back and think that someone else is going to fix > it. > > I'm not sure if its just me, but in the past I've put my hand up to helps > with ops work. Unfortunately, probably due to timezones (i'm in NZ so a lot > of US times don't work very well) and other reasons I've never really been > able to "get into it". So if there were going to be sessions transferring > knowledge, I think it would be useful having recorded sessions for later > watching and also "private" (if necessary) space on the Wiki to store all > things ops (assuming its not already there). > > While we are on the subject, I'd be interested in knowing whether there is > any truth into my understanding that KK is the only one who can release new > Jenkins versions and RCs etc. (I could have completely got the wrong end of > that bit of info!) Only reason I ask is that outside of the infrastructure > single points of failure, that would appear to be another rather large one. > > Cheers > Richard. > > On Tue, Feb 17, 2015 at 3:56 AM, Kohsuke Kawaguchi <[email protected]> wrote: > >> My apologies for a delay in handling INFRA-240 >> <https://issues.jenkins-ci.org/browse/INFRA-240>. As the ticket >> indicates now, I've resolved the problem. The issue was that ldap daemon >> wasn't restarted when I installed a new certificate last week. So it >> continued running with the old certificate, and when it expired, >> Artifactory started refusing to talk to it. >> >> Local apps on cucumber weren't affected because it was using unsecured >> communication. I need to figure out why JIRA and Confluence were unaffected >> by this. Perhaps they have the password locally cached, perhaps they have >> LDAP connections pooled and long-running, or perhaps they don't properly >> check the certificate. >> >> >> The next thing I want to talk about is that I think this is a symptom of >> a deeper issue, which is that the infra ops coverage has fallen way behind. >> Tyler isn't spending time on this project as he used to be, and the time I >> spend on Jenkins infra is not as much as it needs to be, too. >> >> In the last 6 months or so, we've handed out infra acecss right to a few >> more people (Daniel Beck and Oleg Nanoshev, IIRC), and that was good for >> better time zone coverage and what not. But the problem still remains that >> there is a leadership vacuum, that no one sufficiently "owns" the infra, >> and that's difficult to solve by adding more hands alone. >> >> So here's what I'd like to propose: >> >> - Formalize our ops team more by designating the lead that reports to >> the board. The lead shall be chosen in the discussion during the project >> meeting. >> - Under the new lead, accept another round of ops team members to >> help spread the workload. I know for example Kostasya is interested in >> helping. >> - Kohsuke (and Tyler if he can join) and the ops team will schedule a >> series of "transfer of information" sessions to bring the new ops lead and >> the team up to speed about how things are put together today. >> - Identify and remove single-point-of-failure in our infra. Off the >> top of my head: >> - I think I'm currently the only one who has the private key to >> sign update center root CA. >> - jenkins-ci.org domain name still appears to be registered under >> Tyler's personal account. >> >> >> As the ops lead, I'd like the project to consider Adam Papai >> <https://github.com/woohgit>. He's been a long time user of Jenkins and >> he is a member of the CloudBees ops team. I'm sensitive to the fact that he >> works for CloudBees and how that can come across, but OTOH this will be a >> part of his day job, and I think that ensures that he can allocate >> necessary time to the effort. >> >> What do people think? >> >> -- >> 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/fca1745f-2083-48f4-b94c-414be6796d6a%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/fca1745f-2083-48f4-b94c-414be6796d6a%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAMui946PaXMvZ_5ca_aEhaMBUmqHLLswd5%2BYW1uvecjYaAVMRw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAMui946PaXMvZ_5ca_aEhaMBUmqHLLswd5%2BYW1uvecjYaAVMRw%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/CAN4CQ4zKrukLM6ogZz_581o8SQ7_rvBOTZkQnPoZc3Bivm21NA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
