| *** dmsimard is now known as dmsimard|off | 00:22 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Refactor provider config to driver module https://review.openstack.org/488384 | 00:33 |
|---|---|---|
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement a static driver for Nodepool https://review.openstack.org/468624 | 00:33 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement an OpenContainer driver https://review.openstack.org/468753 | 00:33 |
| *** fbouliane has quit IRC | 02:50 | |
| *** _ari_ has quit IRC | 02:51 | |
| *** patriciadomin has quit IRC | 02:51 | |
| *** dmellado has quit IRC | 02:51 | |
| *** leifmadsen has quit IRC | 02:51 | |
| *** _ari_ has joined #zuul | 02:56 | |
| *** fbouliane has joined #zuul | 02:56 | |
| *** patriciadomin has joined #zuul | 02:56 | |
| *** leifmadsen has joined #zuul | 02:57 | |
| *** dmellado has joined #zuul | 02:57 | |
| *** xinliang has quit IRC | 05:58 | |
| *** xinliang has joined #zuul | 06:11 | |
| *** pleia2_ has joined #zuul | 06:13 | |
| *** toabctl has quit IRC | 06:15 | |
| *** pleia2 has quit IRC | 06:15 | |
| *** SotK has quit IRC | 06:16 | |
| *** toabctl has joined #zuul | 06:19 | |
| *** clarkb has quit IRC | 06:22 | |
| *** toabctl has quit IRC | 06:26 | |
| *** toabctl has joined #zuul | 06:28 | |
| *** clarkb has joined #zuul | 06:30 | |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul feature/zuulv3: More documentation for enqueue-ref https://review.openstack.org/518662 | 06:56 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul feature/zuulv3: Make enqueue-ref <new|old>rev optional https://review.openstack.org/518663 | 06:56 |
| openstackgerrit | Ian Wienand proposed openstack-infra/zuul feature/zuulv3: Remove tools/trigger-job.py https://review.openstack.org/518664 | 06:56 |
| *** EmilienM has quit IRC | 07:09 | |
| SpamapS | mordred: we have a crapton of jenkins pipeline stuff here. It would definitely be useful if we could keep using those, but just have zuul kick them off. Especially if they were ultimately backed by the same nodepool and thus carry the same features of fast-start and image refreshing. | 07:34 |
| *** EmilienM has joined #zuul | 09:32 | |
| *** hasharAway is now known as hashar | 10:00 | |
| *** electrofelix has joined #zuul | 10:24 | |
| *** hashar has quit IRC | 11:04 | |
| *** hashar has joined #zuul | 11:05 | |
| odyssey4me | mordred awesome, thank you | 11:10 |
| *** jkilpatr has quit IRC | 11:47 | |
| *** hashar has quit IRC | 12:07 | |
| *** hashar has joined #zuul | 12:09 | |
| *** jkilpatr has joined #zuul | 12:22 | |
| leifmadsen | hrmmm... is there functionality in v3 that lets me call an API directly rather than running an Ansible playbook? | 12:25 |
| leifmadsen | I guess really, the right way to do this, is call a simple playbook, and let Ansible do the triggering | 12:25 |
| leifmadsen | instead of building everything into Zuul... | 12:25 |
| * leifmadsen needs to learn more... | 12:25 | |
| odyssey4me | SpamapS mordred Shrews dmsimard|off I'm adding some notes for the first use-case - it'd be great if we could flesh it out a bit... perhaps even eventually build a spec | 12:37 |
| *** pleia2_ is now known as pleia2 | 13:31 | |
| odyssey4me | Is there a timeline on when the feature/zuulv3 branch will be merged into the master branch? | 14:30 |
| jlk | leifmadsen: yeah, the working model for that is to write a very simple playbook that can use an ansible module to poke at an API, or just a shell task to use curl or whatever. IF all you're doing is hitting a remote url, you can set the job up to not require a node, so that it'll run directly from the executor, super fast. | 15:06 |
| leifmadsen | jlk: awesome thanks, that's kind of what I got thinking after. Good to know about the executor trick too. | 15:30 |
| *** patriciadomin has quit IRC | 15:38 | |
| *** patriciadomin has joined #zuul | 15:55 | |
| *** hashar is now known as hasharAway | 16:26 | |
| SpamapS | odyssey4me: timeline no, but there's a roadmap. | 17:20 |
| SpamapS | odyssey4me: http://lists.openstack.org/pipermail/openstack-infra/2017-November/005657.html <-- this is the most recent statement of roadmap. | 17:21 |
| odyssey4me | SpamapS I guess I'm wondering what the reason is for holding back. | 17:22 |
| odyssey4me | I mean - zuulv3 is implemented, most openstack projects have converted their jobs and things are slowly settling there. Finding the right reference configs at the moment is somewhat confusing as one has to remember to switch to the feature branch. | 17:24 |
| odyssey4me | it's giving some of my colleagues the impression that it's not yet released | 17:24 |
| SpamapS | odyssey4me: you and I agree. jeblair is concerned we might be stuck supporting interfaces we don't want to if we release 3.0 now. | 17:26 |
| pabelanger | yah, I think we are catching our breath too. I know last few weeks have been pretty intense. | 17:27 |
| odyssey4me | ok, so it's not really about the potential to have to switch back now... it's more about being confident with the interfaces | 17:27 |
| odyssey4me | that's fair enough | 17:27 |
| odyssey4me | I guess that makes us in a kind-of 3.0.0.0rc1 state then. | 17:28 |
| SpamapS | odyssey4me: agreed | 17:28 |
| pabelanger | yah, were past the rollback phase now. We're actively deleting zuulv2.5 / JJB content now. | 17:28 |
| SpamapS | Though I don't think it's RC yet. Specifically I think Jim would like to solidify cross-source dependencies, since that could disrupt the interface around Depends-On. | 17:28 |
| odyssey4me | perhaps more of a beta state then I guess | 17:29 |
| pabelanger | yes, he did meantion that a few time a summit this week | 17:29 |
| SpamapS | Personally I'd like to just release. And let that evolve in a 3.1 | 17:29 |
| SpamapS | I'm in the same boat of like "zomg everybody look this is awesome" and hearing "um... a feature branch?" | 17:29 |
| SpamapS | meanwhile OpenStack pumps thousands of jobs a day through it. | 17:30 |
| odyssey4me | Well, I'm looking at using nodepool and jenkins together for now and working through some things. I'm hoping to prototype a short-term hack out within the next week which will be a working implementation, but probably not the most elegant solution. | 17:31 |
| SpamapS | I wonder if we could release Nodepool 3.0 now. | 17:31 |
| odyssey4me | heh, continuous delivery... nothing is stable - everything is just one step to another | 17:31 |
| SpamapS | odyssey4me: yeah but semver is nice for making promises. | 17:32 |
| odyssey4me | nodepool's docs are ok, although it'd be nice to autodoc the model somehow | 17:32 |
| odyssey4me | well - not the model, actually the API | 17:32 |
| SpamapS | And 3.0 definitely has a whole new interface through ZK.. so right now we've made zero promises about that interface, even though it's unlikely to change much given Zuul's heavy use of it. | 17:32 |
| odyssey4me | nodepool and zuul work through zookeeper, and therefore the data model in zookeeper is effectively an API - it'd be good to document which part of that model is intended as an API and which part is intended to be internal | 17:33 |
| pabelanger | odyssey4me: you still want jobs in jenkins? or bridge until you can get everything into zuulv3 | 17:34 |
| odyssey4me | pabelanger it is likely to be something transitional, but might last longer than we hope | 17:35 |
| pabelanger | odyssey4me: yah, talked with mordred about that this week. There is a good use case for sure | 17:35 |
| odyssey4me | yup, notes in https://etherpad.openstack.org/p/zuulv3-jenkins-integration - I added some more | 17:35 |
| odyssey4me | our initial integration is most likely going to be to add a daemon that monitors zookeeper for new nodes and registers them with jenkins (with labels) | 17:37 |
| odyssey4me | then in the jenkins jobs we'll use some groovy to feed the states back to nodepool | 17:37 |
| odyssey4me | once we have something working I'll report back, given that I know there's some interest in this in a broader group | 17:38 |
| SpamapS | Heh.. | 17:39 |
| SpamapS | that daemon's written, and its name is "zuul 2.0" ;-) | 17:39 |
| odyssey4me | heh, yeah - I know | 17:40 |
| odyssey4me | although I though it might be better in this case to write a daemon which can execute any arbitrary command when a new node comes up | 17:41 |
| odyssey4me | then it could be used for any integration - jenkins, bamboo, whatever | 17:41 |
| SpamapS | That's also pretty much what zuul is for. :) | 17:51 |
| SpamapS | Really you just need to run zuulv3 and write ansible that sets up the nodes that the zuul job gets allocated as jenkins slaves and then pokes the jenkins API to run on its jobs them. | 17:53 |
| SpamapS | Then the question just becomes about trigger sources. | 17:54 |
| SpamapS | wow.. that's quite a sentence there.. 'to run on its jobs them' | 18:02 |
| SpamapS | to run its jobs on them | 18:02 |
| odyssey4me | I'm out for the night - cheers all. | 18:03 |
| *** electrofelix has quit IRC | 19:38 | |
| *** SotK has joined #zuul | 19:38 | |
| *** hasharAway is now known as hashar | 20:08 | |
| openstackgerrit | Andreas Jaeger proposed openstack-infra/zuul-jobs master: Add npm-docs job https://review.openstack.org/518789 | 20:32 |
| *** jkilpatr has quit IRC | 20:56 | |
| *** jkilpatr has joined #zuul | 21:13 | |
| *** hashar has quit IRC | 23:24 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!