| *** larainema has quit IRC | 07:53 | |
| *** hashar has joined #openstack-jjb | 08:29 | |
| *** larainema has joined #openstack-jjb | 12:57 | |
| *** sobersabre has joined #openstack-jjb | 15:42 | |
| sobersabre | hi, I remember patching jjb like 2 or more years ago to allow it to ignore self-signed certificates on tls/ssl transports. | 15:43 |
|---|---|---|
| sobersabre | I recently thought of using jjb for a single job that cannot be a pipeline, and wham-bam-bang! jjb still is not allowing this... | 15:45 |
| sobersabre | does this mean nobody develops the tool any more ? | 15:45 |
| zxiiro | sobersabre: we're still developing it. In fact we're gearing up to release JJB 2.0 | 15:47 |
| sobersabre | so... why is disabling of ssl still not merged ? :)) | 15:49 |
| zxiiro | sobersabre: not clear to me what your question is though. Are you asking for pipeline support? I don't personally use it but I have heard the 2.0 code does support pipelines. | 15:49 |
| sobersabre | I'm frustrated and agitated, so I'm not clear. sorry. | 15:49 |
| sobersabre | jjb still does not allow disabling of ssl cert verification. | 15:50 |
| zxiiro | sobersabre: which patch is that? JJB is a volunteer effort as far as I'm aware none of the current core developers work full time on this tool so you might have to ping us in this channel to look at your patch. | 15:50 |
| zxiiro | sobersabre: I know at least for me I work on JJB in my off hours which I don't have many of :( | 15:50 |
| sobersabre | zxiiro: if there is a cleanup process in gerrit, my patch most probably has been cleaned up. | 15:50 |
| zxiiro | sobersabre: can you link to the patch? | 15:51 |
| sobersabre | Lemme try. | 15:51 |
| sobersabre | ok, validated no patches there... | 15:52 |
| zxiiro | sobersabre: you're sure it wasn't merged? | 15:52 |
| zxiiro | sobersabre: not sure if this helps you any but these days I use letsencrypt instead of self-signing my own ssl certs. I find it to be a lot easier. letsencrypt certs work with all the browsers as far as I'm aware. | 15:55 |
| sobersabre | cloning.... | 15:56 |
| sobersabre | zxiiro: I do work effort I'm paid for. maintaining certificates with services adds some kind of work, and I prefer to have customer pay for it. | 15:57 |
| sobersabre | I had totally no need for jjb in the last 2.5 years. | 15:57 |
| sobersabre | since pipeline was rolled out. | 15:58 |
| sobersabre | apr 2015 I think... | 15:58 |
| zxiiro | sobersabre: In case you're not aware OpenStack does not use JJB anymore as they completely switched to Zuul and Ansible so all the full time folks who used to work on JJB stopped contributing. It's now a community project maintained by the folks in this room from other orgs. That's why code reviews are a lot slower now. | 15:58 |
| zxiiro | my org needs this tool still and we're pretty desperate to get JJB 2.0 released. We're just waiting for this one remaining blocker issue to be resolved before getting a release out. | 16:00 |
| sobersabre | zxiiro: just out of curiosity, why do you still need it ? | 16:01 |
| sobersabre | I mean the verb "needs" is pretty strong. | 16:01 |
| zxiiro | sobersabre: All of our infra depends on Jenkins and JJB's the way we still maintain our 1000s of jobs. The templating system in JJB is what's really useful for us. | 16:02 |
| sobersabre | Is $$$ spent on maintaining jjb not worth investing in migration to the pipeline? | 16:02 |
| sobersabre | templating is a hack over the lack of actual programming language with code reuse constructs/facilities.... | 16:03 |
| sobersabre | is the org using too old unported plugins that aren't supported by the pipeline + groovy ? | 16:03 |
| zxiiro | We'd prefer not to go the pipeline route actually. Some of our projects are interested in Zuul so something we're looking into in the future is switching to Ansible and eventually Zuul. Pipelines would cause us to further depend on CloudBees so that's not a good option for us right now. | 16:04 |
| sobersabre | and the numberr of jobs is irrelevant in this talk: how many templates do you maintain? how many LoC ? | 16:04 |
| sobersabre | zxiiro: you mean zuul without jenkins ? | 16:04 |
| zxiiro | yes | 16:04 |
| sobersabre | ah, this is a good point. | 16:05 |
| sobersabre | if one needs jenkins, then pipeline is not an evil :) | 16:06 |
| sobersabre | I've been trying to understand cloudbees positioning, and it's out of my understanding: they don't need big telco customers to pay them. who actually pays them? | 16:06 |
| zxiiro | right and I think Jenkins is fine on smaller projects. but as you start scaling up to the 1000s of jobs Jenkins kinda falls over. Especially if you want to connect 100s of server nodes to it. | 16:07 |
| sobersabre | zxiiro: I see that projects like ovirt survive ok with 1000s of jobs by using multi-master arch, and some zuul help. | 16:08 |
| zxiiro | That's a good question. I'm not sure but I went to one of hte CloudBees conferences 2 years ago and they seemed to have a pretty big marketing push. One of the guys told me the purpose of their conferences for them is sales. | 16:08 |
| sobersabre | but I totally agree that it's non-necessarily "the right tool for the job". | 16:08 |
| zxiiro | so there must be enough folks buying the enterprise stuff | 16:08 |
| sobersabre | rh/ovirt isn't paying to cloudbees. | 16:09 |
| sobersabre | (AFAIK) | 16:09 |
| sobersabre | they are using community version and plugins. | 16:09 |
| sobersabre | so it's more of code contributions and ... increase of user base kind of "payment". not direct cash flow | 16:09 |
| zxiiro | yeah we're using community version as well. Unfortunately the plugin side of things it's been hard to get them to fix stuff (but fair enough we're not paying them anything) | 16:11 |
| sobersabre | we're fixing stuff for our customers, and push them to upstream. | 16:11 |
| sobersabre | customer sometimes is happy to pay and know it doesn't need to be maintained by them. | 16:12 |
| zxiiro | we've been trying to do that as well but our team is really small and there's a lot of other projects we depend on so we have to pick our battles of where to contribute. For me at least it's been JJB, I'm hoping the work I've started on Ansible will make us depend on less Jenkins plugins though. | 16:13 |
| sobersabre | you're talking about openstack zuul, right? | 16:13 |
| zxiiro | sobersabre: yes | 16:14 |
| sobersabre | (there's netflix zuul) | 16:14 |
| zxiiro | well that's confusing but good to know haha | 16:14 |
| sobersabre | netflix guys like to confuse people with their chaos monkeys. | 16:14 |
| zxiiro | yeah the latest version of Zuul uses Ansible playbooks to run jobs so a first step to swtiching would be converting our jobs to playbooks | 16:14 |
| sobersabre | zxiiro: are you wrapping things like mvn, sbt, cmake with in-house modules, or are there ready ones ? | 16:15 |
| sobersabre | and there's nodejs build things, ruby, and old gnu autotools... | 16:16 |
| zxiiro | sobersabre: not sure yet. I am aware of an openstack-ansible repo containing a bunch of playbooks. so I'm hoping other orgs have something similar for the different pieces so that we don't have to maintain the bits we need but I've only started looking into this. Still learning it myself. | 16:16 |
| sobersabre | zxiiro: in good ansible code base a playbook is as empty as possible - usually triggering roles. roles trigger tasklists (each task triggers modules) | 16:18 |
| sobersabre | if you need to customize - you're passing extra vars (I usually advice to do it via extras.yml file and retain it for debugging, when possible) | 16:18 |
| sobersabre | so, when you're saying 'playbooks' it hints me they are hard-coding variables in playbooks, specifying stuff and then you cannot re-use a playbook. I hope I'm wrong :)))) | 16:19 |
| sobersabre | by "good" I mean following standard ansible documentation for style and organization... | 16:20 |
| zxiiro | hmm ok thanks for the tip. Yeah I haven't figured out the roles stuff yet. I literally only started reading about this 2 days ago. | 16:20 |
| sobersabre | ansible is "just a tool" ;) | 16:20 |
| sobersabre | but it's nice and easy to grasp. | 16:21 |
| sobersabre | in any case O(10^3) of jobs is not the upper limit for jenkins. | 16:23 |
| sobersabre | unless you're running them in parallel. | 16:23 |
| waynr | i hope to someday not use jenkins at all for CI/CD | 16:30 |
| waynr | i don't like the approach of "everything you want to do in CI/CD should be a plugin", ie running ansible playbooks, running docker containers, running maven, etc | 16:32 |
| zxiiro | same, although it is a form and vendor lockin. I dislike it because it's hard to fix if something's not working right. Now you have to become a developer on that platform to get it resolved. At least if the option of shell is always available to you can usually work around the issue. | 16:35 |
| waynr | it's a form of vendor lock-in but even worse for the jenkins project it makes major changes to the underlying system by the developers untenable. anything that breaks compatibility with the existing community of plugins is going to alienate their userbase so they avoid making design decisions that might do so | 16:37 |
| waynr | while pipeline makes sense from a committed jenkins user and jenkins developer perspective, i think it's overall a step in the wrong direction for CI/CD in general | 16:39 |
| openstackgerrit | Jonathan Rajotte proposed openstack-infra/jenkins-job-builder master: Fix: use False for default value of query_plugins_info https://review.openstack.org/527804 | 16:39 |
| waynr | i'd like to see a backend-agnostic CI/CD DSL that can transpile into configuration for multiple different backends; ie Openstack's Zuul, Jenkins 1.x, Jenkins 2.x Pipeline, GoCD, etc | 16:41 |
| waynr | well i wouldn't just like to "see" it, i'd like to design and implement it ;) | 16:42 |
| zxiiro | same actually | 16:45 |
| zxiiro | and it's part of the reason I like shell scripts. it's portable | 16:46 |
| zxiiro | at least more so than all these Jenkins plugins. | 16:46 |
| waynr | yeah | 16:47 |
| *** caphrim007 has joined #openstack-jjb | 17:39 | |
| *** caphrim007 has quit IRC | 17:49 | |
| *** caphrim007 has joined #openstack-jjb | 17:49 | |
| *** caphrim007 has quit IRC | 17:50 | |
| *** caphrim007 has joined #openstack-jjb | 17:51 | |
| openstackgerrit | Merged openstack-infra/jenkins-job-builder master: Fix: use False for default value of query_plugins_info https://review.openstack.org/527804 | 18:19 |
| *** larainema has quit IRC | 20:10 | |
| sobersabre | waynr: I disagree with the generic and backend agnostic approach. the wider you think the more you must test. the harder it is to have it stabilized. so the implementation should be 1 backend based. and opinionated backend, opinionated approach. | 21:34 |
| sobersabre | Jenkins' main problem is its age: it was designed in the beginning of 2000s, and the problem with abundance of plugins. | 21:34 |
| sobersabre | but plugin based pattern is a good pattern. | 21:34 |
| sobersabre | until it starts hitting stability... | 21:35 |
| sobersabre | as to ci/cd, a company with enough expertise in the process development (dev/ops), would like a toolkit over a solution. | 21:39 |
| sobersabre | A company without hr will want a solution. | 21:39 |
| *** hashar has quit IRC | 23:05 | |
| waynr | *shrug* | 23:27 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!